You know what they say, “What happens in Vegas, stays in Vegas”. In this case we are willing to share a little of what transpired while we were at the Las Vegas Scrum Gathering last week in Las Vegas, NV. As usual the Las Vegas Scrum Gathering was an amazing conference full of lots of learning and meeting new people. We had 4 Braintrust team members who co-presented/presented 3 separate sessions. Want to see what we presented? Click the links below to download our presentations.

1. John Miller, CSP – Coach The Hand You Were Dealt – download here
2. Kate Megaw, CSP & Lonnie Weaver-Johnson, CST – Metrics:How Will You Know If You Are Gambling With Scrum? – download here
3. Brian Rabon, CST – ScrumMaster Maturity Model – download here

Did you miss us at the Las Vegas Scrum Gathering this year? Mark your calendar for and come visit with us at Agile 2013 in Nashville, TN

.

Coming soon…

It’s symposium time again! Brain M. Rabon, CST, PMP, President of The Braintrust Consulting Group, will be facilitating 2 back-to-back workshops on Friday, April 12 at the PMI Central Florida 2013 Symposium.

Brian will be sharing information on “Raving Retrospectives” during the Friday morning workshop at the Hilton Orlando in Orlando, FL. Brian will teach workshop attendees how to spice up their lessons learned meetings with multiple new innovative techniques, games, and other creative methods.

In the afternoon Brian will be presenting Braintrust’s very own “ScrumMaster Maturity Model”. You will get to take an assessment to see where you fallout in the model, as well as learn tools and techniques to help you become a better ScrumMaster.

Brian will bring his passion for teaching to this workshop and you’ll walk away with something you can implement immediately. The techniques that Brian employs in his classroom workshops, as a Certified Scrum Trainer®, will be evident throughout the morning. Participants will be able to apply what they learn with activities interwoven throughout this workshop. Tired of the same old non-productive retrospective meetings? Then come spend the morning with Brian at the Central Florida Symposium this Friday, April 12, 2013.

The Braintrust Consulting Group is proud to be a sponsor of this event and looks forward to seeing you in Orlando this weekend!

Want more? Join us for one of our upcoming Certified ScrumMaster (CSM) or Certified Scrum Product (CSPO) classes in the Orlando area:

• June 10 – 11, 2013 – Certified ScrumMaster (CSM)
• June 12 – 13, 2013 – Certified Scrum Product Owner (CSPO)
• December 16 – 17, 2013 – Certified ScrumMaster (CSM)
• December 18 – 19, 2013 – Certified Scrum Product Owner (CSPO) w/ free iPad

Would you like the slides from Brian’s workshops? You can download them Raving Retrospectives here and ScrumMaster Maturity Model here.

Want to see pictures from this workshop? Check out our Facebook page at http://www.facebook.com/braintrustgroup.

As users of the Agile methodology, you are all aware of the sprint. The more you do the sprint, the more you find that its usefulness is dependent on the effort that you put into it regardless of your role on the team. Below are seven surefire ways that you can kill the sprint’s effectiveness.

• Begin with an irregular sprint schedule, or better yet change the sprint schedule in the middle of the sprint run. Allowing the workload to be dictated by someone other than the team ensures that your sprints will be on an irregular schedule.
• To give time back to your team members, simply require an email, a tweet or text message, an entry on a spreadsheet, or even a phone call from every team member to provide an update on their status. The daily standup meeting is too tough to coordinate because the team works a flexible schedule. Good team members should be able to collaborate electronically and be just as effective.
• Sprints carry too many deliverable products to track. Instead of requiring a shippable product from the team at the end of each sprint, just work towards the end goal. The customer can test the product as a whole when it is complete, and in the process the product owner gets to eliminate all of the overhead that comes from tracking progress. All the team needs is a deadline and requirements.
• Speaking of requirements, once a product owner has met with the customer, they should have everything they need to complete the project. After all, once everyone agrees on the requirements, specifications, and the due date, all the customer should be concerned about is the deliverable. Once the deliverable is ready, then you can get back with the customer. No need to communicate progress or status – we all agreed on this at our one meeting.
• Stakeholder management is just too complicated. Being able to send out a dashboard with the project status should be good enough. If a stakeholder has a question, they should contact the customer. The team is simply responsible for is creating the product, but the customer is the one who is responsible for the success or failure of the product in their organization. So in reality, the customer should be more concerned with stakeholder management than the project owner.
• If someone on the team encounters a roadblock, they should work on clearing that roadblock themselves. The reality of today’s environment is that everyone is constantly interrupted and priorities change daily. Part of a team member’s professional growth is in learning how to deal with those types of issues.
• Managing a backlog is another administrative task that can be eliminated. Once the requirements are set, the team has all that they need to complete the deliverable product. A good team should be able to break down the tasks and parts that need to be completed in order to ship the final product. Why does there need to be a meeting to accomplish this?

This is obviously a tongue-in-cheek look at the sprint, and members of a Scrum team would never intentionally do this. If this approach is taken, then the project likely will end up as a colossal failure. But you might find one or two here that you could be slipping into because of demands on your time or simply complacency. If so then hopefully this is a good wakeup call. Let us here at Braintrust help solve your problems! With our experienced team of Scrum coaches, Braintrust has the experience and resources to help you do Scrum in a world-class manner. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.

Today is Christmas Eve. Gifts are bought and wrapped under trees all around the world. Everywhere kids of all ages wait with great anticipation when they can finally tear into those gifts and see what they received.

And then, in some cases, there’s the letdown. The color isn’t right. Or I already have one of these. Maybe they bought you a medium when, ahem, an extra large is required.

You thought that someone knew what to get you. After all, they should just know me, right?

The reason for the disconnect is that nobody is a mindreader. I’ve been trying to convince folks, including my wife, of that for years.

And so this can happen with your projects also. Without effective communication between the project team and customers or stakeholders, projects can proceed with both parties assuming that the other knows exactly what they’re thinking. And unfortunately, this is when a project breaks down – the developers simply don’t understand what the customer’s requirements are.

A 1998 study conducted in the United Kingdom sought to find the primary cause of delayed project delivery and project failure. At the very top of the list – a breakdown in communications, cited 57% of the time.

Communications have been around since the dawn of business. While there may be new channels for communication, there basic premise of communication remains the same. No single project management methodology or tool will help to fix this either. But there are things that your organization can do to minimize this type of problem. As a Christmas gift to you, here are three non-tech ways to improve your communications within your organization:

Get to know one another. In the last month I’ve taken on a new role. My first order of business was to meet for 30 minutes, one on one, with everyone in my department. We didn’t talk about anything in particular, but at the end of each meeting I knew something about each person and them about me. And I’m sure we both will feel a lot more comfortable interacting when the first business issue comes up between us.

Hold face-to-face communications whenever possible. Depending on which study you read, up to 93% of all messaging comes from non-verbal communications. Things like tone, rate of speech, inflection and body language all communicate so much more than the words being used. Technology makes it easier than ever to communicate, but much of the meaning is lost when the message is translated into ones and zeroes. It is very tempting to hide behind technology when a controversial subject needs to be discussed, but that is the least effective way to resolve conflict.

Personalize your interaction style with your audience. The more you know the individual or audience that you are communicating with, the better you will be at tailoring your style to fit their needs. Our different personality traits demand a personalized style of communication to feel at ease and to get the intended message across.

Tired of searching for a qualified mindreader? Are communications an issue in your organization? If so, let us here at Braintrust help solve your problems! With our experienced team of Scrum coaches, Braintrust has the experience and resources to help you communicate better with your team, your customers, and your stakeholders. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.

Photo courtesy of Bernt Rostad via Creative Commons.

Well-done. Medium, Medium-rare. How do you like your steak to be done?

As long as it’s cooked right, and it comes from good beef, it doesn’t really matter to me what type of cut it is. It’s hard to beat the flavor and the juicyness of a steak that’s prepared the right way. But when I cut into a steak that hasn’t been prepared the way I like it, then I just cannot eat it. In general, this happens because my definition of “done” doesn’t match the preparer’s definition of “done.”

This problem can creep into your Scrum projects as well. In this post we’ll talk about what creates this problem and how to avoid this situation.

In Scrum, each iteration of the Sprint cycle produces a potentially shippable product increment. During the Sprint Review session, the Team gets the spotlight. They get to share with the stakeholders and the customer the work that they’ve completed over the last Sprint. If the expectations of the customer line up with what the Team delivered, then everyone is happy. But sometimes that doesn’t happen. The customer comes in to the Sprint Review expecting one thing but gets something else instead. So while the Team Members may agree that a particular feature is “done,” the Product Owner or the Customer may not.

In order to avoid this situation, here are seven tips to get you started:

• Have a fully engaged Product Owner. Because the Product Owner is the customer liaison to the team, they are the critical link in understanding what is most important to the customer.
• Create well-worded, specific User Stories. The best User Stories describe the role of the user/customer, what they want and expect from the product, and what benefit the feature brings. These are the easiest to translate into features for the backlog, and in turn become good requirements and tasks for the team.
• Ask questions. Don’t assume anything. It is ALWAYS better to find out early that your assumptions didn’t meet the customer’s expectations. If something is unclear, never be afraid to ask good questions in order to clarify what the customer wants.
• Estimate well. You might think this doesn’t have anything to do with feature completion. However, it is human nature to feel pressured to meet the estimates that we set for ourselves. A poor estimate can lead to rushed work, which in turn can cause a feature to not be completely done.
• Choose Product Backlog items wisely. By picking complementary items from the backlog, the Team has a better chance of success. If team members choose items that are all across the board, they may miss a critical dependency between items that may not be part of the current Sprint’s backlog.
• Keep you Product Owner informed on your team’s progress. Communication is critical, and if the team is struggling then the Product Owner needs to know this early on. In this way, the Product Owner can keep the customer and stakeholders apprised of issues that may not appear on the burnup/burndown charts.
• Test, test… and test some more. There is no substitute for determining if a feature is done other than comprehensive testing.

So that’s our quick and dirty tips for avoiding the question of “done.” If these aren’t enough, let Braintrust help! With our experienced team of Scrum coaches, Braintrust has all sorts of experience and resources available to help you know, beyond a shadow of a doubt, when a product is done. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.

Photo courtesy of natalie lusier via Creative Commons license.

As ScrumMaster, you will face many difficult situations. Though Agile, and Scrum in particular, are wonderful frameworks in which to run a project, no tool or framework guarantees success. Because you deal with people, the variable that they introduce can stretch your patience. When that happens, everyone watches to see if you’re good at keeping your cool. In this post, we’ll discuss ways that the ScrumMaster can keep his cool and pilot his team through these treacherous waters.

For starters, just breathe. When we get wound up about a particular subject, it’s easy to go on a tirade. Just listen to people who do this – some of you may call it a rant. They talk fast, the pitch of their voice rises, and they get louder and louder. Whenever we’re faced with a challenge, adrenaline kicks in to help us power through that situation. Unfortunately, that’s not so good when we’re dealing with people in a professional environment. If you find yourself being dragged into a situation, pay attention to your breathing. Drawing deep, rhythmical breaths can help you clear your head and not respond so quickly.

Deal with conflict in person. Remember that 93% of the message in communication comes from tone, pitch, rate of speech, and nonverbal cues such as body language. Only 7% of the overall message is conveyed in words. I believe that a conflict which is resolved over email or text is never fully resolved because so much of the communication is lost.

Next, listen more than you talk. One of Stephen Covey’s seven habits is “Seek first to understand, then to be understood.” While you’re trying to get in your comments, you’re missing what the other party might be saying. Even if they’re being combative, stop and listen. By doing so, you exhibit great control and your professionalism naturally comes through. This gives you the upper hand in any negotiation – although it’s our nature to fight back and defend ourselves.

Always ask questions. This one also plays into the Covey habit given above. The more you seek information with good, targeted questions, the more time you’ll have to formulate your next step. One of the common characteristics of good leaders is their ability to ask good questions. This is true regardless of role, position, or industry – the ones that ask the best questions are always seen as thoughtful, probing, and even-keeled.

Consult with your team. The real talent on a Scrum project lies in the experience and abilities of the team. Present the issue to your Scrum team members. Together they may come up with innovative solutions that you alone may not have thought of. They will respect you for involving them in something that will affect them down the road. And in their discussions, you just might find the up and coming leaders on your team.

Offer several options for resolution. The old saying goes that there is always more than one way to skin a cat. Offer up creative solutions, even if they feel counterintuitive. If you demonstrate your willingness to be flexible and adaptable in a tough situation, then perhaps you’ll win the next one. Unless it’s life or death for the project if something isn’t done, be willing to give in sometime. Lose the battle in order to win the war.

Do you struggle with keeping your cool in tough situations? What other creative ideas do you have that demonstrates control under pressure? Maybe you have stories from your own projects that you’d like to share with our readers. Conflict is unavoidable – how you handle it will determine your effectiveness at leading great Scrum teams. And keeping your cool doesn’t require a trip to the Arctic either.

Photo courtesy of cwbuecheler via Creative Commons

One of the most popular courses offered by Braintrust Consulting Group trains one to become an effective ScrumMaster. While there are many duties and tasks that the ScrumMaster is responsible for, none are as important as those related to communication. It is crucial that the ScrumMaster has information readily on display for his team, his product owner, his customers and stakeholders, and for other interested parties. In Scrum, we use the phrase “information radiator” for this type of artifact. For this reason, I chose the word “radiant” to describe the effective ScrumMaster in this post.

In the post “A ScrumMaster’s Checklist” by Michael James, he makes several references to the need for effective information radiators at all levels. An information radiator is nothing more than a prominently displayed collection of information. By prominently displayed, I mean that someone who passes by the display cannot help but receive the information contained on the display. Just like the radiator pictured above, if you get close to it you will feel its effects. Interested parties don’t have to dig for information when information radiators are used effectively. Information radiators generally become part of the project artifact collection in Scrum.

In Scrum, several of the information radiators in use are:

• The Scrum, or Kanban board
• Burndown/burnup charts
• Sprint backlog
• Product backlog
• Task lists
• Estimates
• Impediments and roadblocks

For an information radiator to be trusted and referenced, it must remain up to date. The effective ScrumMaster ensures that all of the information radiators related to his project remain current and accurate. Otherwise, the ScrumMaster, or worse the Team Members, waste time by providing up-to-date information when an inaccurate or outdated data point is uncovered. If this task isn’t taken seriously, then the ScrumMaster may as well take down the information radiators because nobody will use them.

The list above certainly isn’t all-inclusive. As the ScrumMaster becomes more adept at running Agile projects, they will begin to develop information radiators that meet their organizational needs. One way to identify these is to simply pay attention to the information being requested over and over. Another is to reference project artifacts from past successful projects. Or, you can simply ask other ScrumMasters in the organization what has worked for them in the past.

So what information radiators do you use in your shop? Do you feel like you’re doing a good job with these, or are you consistently asked for information and data that isn’t readily on display? If you’d like to learn how to be more “radiant” as a ScrumMaster, then let Braintrust be your guide. With our experienced team of Scrum coaches, Braintrust can both train new ScrumMasters in the Agile methodology or help experience ScrumMasters get better in their own practices and methodologies. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.

Photo courtesy of frankdouwes via Creative Commons

I had a chance encounter with a seagull a few years back. I was riding on a ferry boat between Lewes, Delaware and Cape May, New Jersey when a seagull did its business on me. Needless to say it was gross. I think the seagull is a nasty bird with a nasty habit and a nasty disposition. The term “seagull manager” has emerged to describe a manager who acts in a similar manner. In this post, we’ll describe the seagull manager and give you a self-assessment tool to see if you have those tendencies.

A seagull manager is characterized by their interaction with their team. The only time you hear from them is when there’s trouble. They fly in, poop all over everything, make a lot of noise, and leave their mess behind for everyone else to deal with. They are short on relationship and don’t want to be bothered unless you’ve got something for them. When they’re around, they are very critical of everyone and everything.

Ask yourself the following ten questions to see where you might fall on the seagull manager scale.

Does your team look forward to seeing you or do they avoid you?

Do you regularly communicate with your team or only in times of crisis?

Do you make yourself available to your team or is your policy “don’t call me, I’ll call you”?

Do you make regular time for one-on-one interaction with your team or is it all generalities with everyone?

Do you ask your team for their opinion and insight or is it your way or the highway?

Do you give your team the recognition and credit for their work or do you talk in terms of what you accomplished?

Do you know your team personally as individuals or are you just too busy for stuff like that?

Do you communicate with your team face to face or do they expect emails and texts from you?

Do your actions match your words or would your team say that you have a problem with integrity?

Do you focus on results only, or are the behaviors and processes more important?

Now that you’ve recorded your answers, pretend that your team was asked these same ten questions about you. If you believe that their answers might be different from yours, then perhaps you might be a seagull manager.

I won’t give you the right or wrong answers to these questions – that’s up to you to decide. If you’ll re-read the seagull manager description above I think you’ll get the picture. As a ScrumMaster or Product Owner on a Scrum Team, your team depends on you in a leadership or managerial role. If the only way you act with your team is as the seagull manager described above, then your team and your projects are suffering.

Do you feel as if you have the tendencies of a seagull manager? If so, let Braintrust Consulting help you correct those tendencies. With our comprehensive course selection, we train more high-quality ScrumMasters and Product Owners than anyone in the Southeast region. Leave the old you behind with some valuable training from BrainTrust! Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.

All companies that produce software products experience technical debt. As a member of an Agile team, technical debt affects your velocity. In this post, we’ll briefly explain both technical debt and velocity and make the connection between the two concepts.

Let’s begin with technical debt. In short, this can be described as unfinished business. It occurs when a task, requirement, feature, user story, or some other aspect of the project is incomplete. Technical debt takes on many different forms. Bad design, incomplete testing, bugs, unknown requirements, and others make up the universe of technical debt. Left unmanaged, technical debt can swallow a software product. Technical debt can rise to the level where the team can add no new functionality to a product. All they are able to do is fight the problems associated with technical debt.

Velocity is a measure of how fast a Scrum team delivers business value. It is represented as a number that is tied to the team’s estimates for all of the tasks, features, user stories or backlog items completed during a Sprint. Velocity can fluctuate but should begin to stabilize across multiple Sprint iterations. Once a predictable velocity is established for a team, it can be used in Sprint planning to determine how much work a team can take on for that Sprint.

Now that we have a brief overview of each concept, I hope you can begin to see why technical debt affects your velocity. I like to think of technical debt as a weight that has to be dragged around by the team. Until the weight is cut free, the overall efficiency of the team is going to be affected. Dealing with technical debt issues may cause your team to overestimate their backlog items. Thus, fewer backlog items can be completed during a Sprint because the estimates begin to add up quickly.

It may also cause your team to avoid different backlog items because of the lingering technical debt. They may fear that the associated work is so difficult to address that they feel uncomfortable taking ownership of that particular backlog item.

Not surprisingly, there is also an reverse relationship between velocity and technical debt. That is, depending on how velocity is used and reported, it can affect the technical debt weighing on a project. Here’s why – if a team is being pressured to improve their velocity, they may begin to cut corners. Testing can suffer, bugs can be overlooked, and collaboration may be minimized when a team is pushed to perform at a velocity that is not optimal for them.

If you find that the technical debt is piling up, let Braintrust Consulting Group help you find and fix the underlying problems. With our experienced team of Scrum coaches, Braintrust can help you overcome these issues and provide your team with the tools necessary to manage technical debt effectively. We can also help you find the optimal velocity for your team. We will factor in their working styles, their abilities and skills, and give them the know-how to estimate with confidence. Click on the Contact page to hear from one of our product specialists. Or, head over to the Services tab to find out more about our offerings.