Geeks With Blogs

The Life and Times of a Dev Yes, we're really that weird

When teams are first introduced to Stand-Ups, many teams will dread them.  Their thought is, “Oh great!  Yet another meeting to consume a bunch of my time!”

I certainly understand this sentiment, and if run incorrectly, stand-ups are certainly painful and can be a waste of time.  Stand-ups are fundamentally about coordination between team members and nobody else.  To restate that, stand-ups are for the pigs, not the chickens!

This post is to help you understand what a good stand-up is and how best to keep people from dreading your stand-ups.

What is the Stand-Up?

Before I jump into how to make a stand-up effective, I’d like to talk more about what a stand-up is.  The basic structure of the stand-up is this:

  1. The team gets together at a regularly schedule time
  2. The team meets every day at the same time
  3. Everyone on the team attends
  4. The ScrumMaster starts the meeting on time and picks the first team member to start
  5. The team coordinates around the questions:
    1. What did I do yesterday?
    2. What am I working on today?
    3. Is anything blocking me?
  6. The stand-up ends when everyone has had a chance to answer the questions
  7. After the stand-up, the ScrumMaster helps resolve any blockages identified during the stand-up

That’s it, but many teams try to make it much more complex than that.  Because of that, next I’ll try to give some examples of how people fail with stand-ups.

Stand-Up Dysfunctions

I’ve seen several types of dysfunctions in my years as a ScrumMaster.  They tend to be quite common, and all can be addressed.  Interestingly, “long” stand-ups are usually a side effect, not a problem!  With the exception of teams that are too big, I’ve never seen stand-ups go long on a regular basis for teams that are functioning well.  Here are the most common issues I’ve seen in Stand-Ups.

  1. Using stand-ups to report to management
  2. Using stand-ups to solve design issues or other problems
  3. Monopolization of stand-ups by either pigs or chickens
  4. Lack of participation from certain team members

Using Stand-Ups to Report to Management

This is, by far, the most common problem with Stand-ups.  Note that Management can include the ScrumMaster.  A key sign of this happening is that team members are required to bring in story numbers, defect numbers, etc. to the stand-up and tell exactly what they did for each story.  Team members will typically make eye contact with the manager or ScrumMaster to whom they’re reporting.  When reporting like this happens, Management will often give feedback or direction during the Stand-Up.  This is a great example of a Chicken talking when they shouldn’t be.

Of course, this can be tricky, since Management often controls your paycheck, but as a ScrumMaster, and as a team, you need to make sure that the team has the time to coordinate that they need.  One way to solve this problem is to ask the manager in question to not come to the stand-up for a week and promise that you’ll give him detailed information about what was said.  If they’re a good manager, they’ll probably go for this.  This will let you reshape the stand-up to be about coordination.  You’ll be able to introduce new interaction styles between the team members.

Another strategy is to ask the manager to not talk during the stand-up.  In fact, if they’re willing, have them focus on their phone, like they’re dealing with important e-mail messages.  Breaking eye contact has an interesting effect on people’s behavior.  We expect that the people we’re talking to will look us in the eyes.  By breaking eye contact and not talking, the team won’t feel like they’re talking to the manager and they’ll be more likely to make eye contact with other team members.

A third strategy is to actively look for points of coordination and call them out; give them special attention.  That will start people thinking in terms of coordination and over time, they’ll start to coordinate normally.

A final strategy is to ask, after every report, “How can we help you with that?” or “Is there anything that you need to coordinate around those items with the team?”

Using Stand-Ups to Solve Design Issues

This problem also really happens frequently.  Basically, a team member will bring up a problem, and the rest of the team begins to try and solve the problem.  This collaboration is great, and you want to foster it in general, but not during the stand-up.  My strategy here is to try and make a determination as to how long the discussion is likely to take.  If you’re working with a small team, a little more talk can be tolerated.  If the conversation appears to be likely to take a lot of time, simply say, “Can we take this offline?”  If the team doesn’t respond well to that, interrupt and say, “This is a great discussion.  We need to move on with the stand-up, so I’ll schedule a meeting where we can continue this discussion.  Who’s next?”

Most teams will respond to the first well, some will require you to be more forceful, but curbing design discussions can greatly enhance your stand-ups.

Monopolizing Stand-ups

Some team members just like to hear their own voices!  Sometimes, it’s because they’re really happy with what they’ve created.  Other times, they just don’t know how to filter the content that they’re giving.  Sometimes, they do it to try and manipulate the stand-up.  Often, team members are giving details on how they did something, rather than what they did, or are treating the situation as a reporting situation, rather than a coordinating situation.

Monopolization is most typically solved by individual coaching of team members.  Don’t do it in stand-up, unless you give the feedback generically at the beginning of your stand-up.  Instead, talk with the team member and then do role playing.  Most people are very receptive to this type of coaching and will gladly change, if that will make stand-ups shorter.

Some people are more recalcitrant and will require more work.  Be patient, and if you can get the rest of the team to function well, they’ll see that they’re standing out and be pressured to change.

Another strategy is to tell everyone that they’ve got 2 (or whatever) minutes to give their stand-up.  Then, bring an egg timer into the meeting and use it for each team member.  When it goes off, they’ll know they’re going over.  The noisy bell tends to be very effective at getting people to focus their thoughts.

Lack of Participation

This is a tough one.  This usually happens when people are resisting the change to agile.  I’ve actually heard, “Yesterday, I did stuff.  Today, I’ll do some more stuff, and I’m not blocked.”  I’ve heard that when people were joking, but I’ve also heard that from people that were serious.  Without major attitude change, team members that behave this way are going to cause major disruptions on the team.

First, try approaching them and giving them coaching about how their behavior is impacting the team.  If they still resist, become more blunt.  If they still resist, you’ll need to get HR involved, and they may not be the right person for the team.  Remember that technical ability does NOT trump the ability to work on a team except in rare cases.  If they don’t change, move them out.


I hope that this has been useful in helping you understand how to make your stand-up more effective.

Technorati Tags: ,,
Posted on Monday, October 17, 2011 11:59 AM | Back to top

Comments on this post: Effective Stand-ups

# re: Effective Stand-ups
Requesting Gravatar...
So "Worked on defect yesterday, working defects today and not blocked" probably isn't good either? :)
Left by Pete on Oct 17, 2011 2:57 PM

Your comment:
 (will show your gravatar)

Copyright © Robert May | Powered by: