Standup meetings: Keeping them useful

Every morning, we religiously hold a stand-up meeting to share information around the team - or at least, that is what's meant to happen. Over time, I've noticed that the whole idea of the meeting has been lost and people now attend the meeting because that's what they did yesterday and so it will go on until someone tells them to stop. The stand-up meeting is a technique taken from the Extreme Programming model and I believe it works effectively if you use it correctly.

A stand-up meeting every morning is used to communicate problems, solutions, and promote team focus.

So what does this mean? It means, you have to come to the meeting having prepared a synopsis of what you achieved yesterday focusing on the problems and solutions only. Don't talk about anything else. We only want to hear successes or failures and not all about your daily churn. Remember the audience that you are talking to - developers, testers, PMs, BAs, etc. They all have different interests but as a whole, they all must come together to ensure communication is effective across the team. This is the whole point of the meeting and everyone who speaks should bear this in mind and focus their content to suit the audience.

As a reference, here are some things I believe are not worth mentioning:

• Daily churn - by this I mean we don't want to hear that you fixed a few bugs, added a comment to the order class and corrected a few spelling errors. This is not helpful information and doesn't affect anyone else apart from you. If you do fix a few bugs, say what they were and why they will help other people.
  
• How you are tracking against your estimates is not productive on a daily basis because it's too granular. Project teams should also hold a weekly meeting that is more appropriate for this type of information. By all means highlight glaring errors in estimates, but don't talk about why you ran over by an hour on your last story card.
  
• Anything that is implementation specific - remember your audience, save geek-speak for developers.
  
• Any problems you are having that are not related directly to the project you are working on.

Typical things that I'd be interested to hear at the meeting are:

• Solutions and successes. For example, we've worked out a more efficient way of loading information from the database. Or we have changed the structure of the build file making it easier to maintain and it has reduced the build time. People want to hear about what you've been doing and if anything you have done can help them in the future.
  
• Problems - this means areas of the system that are causing longer development times or are very difficult to maintain. If you don't understand what or how you are meant to do something, raise this and identify someone who can help. If you sit on your own and never mention your problems, no one will know to offer help.
  
• Milestones or notable achievements - everyone likes to celebrate.
  

If you have nothing worth saying, don't say anything. You are not required to say anything but you should always attend the meeting to hear what other people have to say. I bet that if you were to ask a team to repeat what someone said in the stand up meeting yesterday, they would not remember unless it was notable. No one wants to remember useless or boring information but we are "programmed" to remember anomalies so focus your information on notable items.

Finally, remember the rationale behind the meeting and why stand-up meetings are part of the XP methodology. As a team, we want to be continuously improving and each member of the team should be making suggestions to ensure this happens. The stand-up meeting is a forum for everyone to discuss their daily findings and making sure that, as a team, we solve those problems. Also remember that a stand-up meeting is not an excuse to stop talking during the rest of the day. It's more likely that you will talk to people in a similar role during the day and this should always continue, but use the stand-up meetings to bring the roles together and to form a team that communicates information effectively.