The Agile Architect
The Agile 5 Minute Daily Standup
- By Mark J. Balbes, Ph.D.
It's time for your next meeting. You take the five minute walk to the only conference room available which is, of course, in the next building over. With laptop in hand, you enter the room, pleased to discover that it is roomy, comfortable and, best of all, there's available power. Plugging in your laptop, you settle in for the scheduled one hour team status update. Your next meeting starts right after this one, so even if this meeting ends early, you know you aren't going back to your desk.
So you do the only thing that makes sense: You stick your head in your laptop and start to work. And then the meeting starts. People are talking. But you are getting work done on your laptop. Your colleagues are doing the same. You fool yourself into thinking you are paying attention to the meeting. Your manager is droning on about something you think you already know. You'll perk up if he says something interesting, you tell yourself. Sure you will. Welcome to meeting hell!
What Is a Standup Meeting?
The daily standup meeting was made popular by Scrum but has been adopted by many agile teams regardless of the methodology they follow. The intent is for the team to quickly share status and then get back to work. And yes, you do really stand up. Coupled with team collocation, stand up meetings are an effective way to keep meetings to a minimum while accomplishing what needs to be done.
In Scrum, the daily standup revolves around three questions.
- What did you do yesterday?
- What will you do today?
- What is getting in your way?
This tends to lead to a discussion focused on the individuals on the team, with each reporting their status. As the team gets larger, the standup gets longer. When team members don't have anything worth discussing, they may still feel obligated to make some comments and fill time.
But the standup doesn't have to be that way. As agile methodologies advance, different teams have different uses for the standup.
Ways to Improve your Standup
If you find that your standups are useful and effective, that's great. This article may not be for you. If you find that your team is having a standup meeting because they are supposed to but not really getting much value out of it, here are some suggestions.
Focus on the Work, not the People
Rather than asking what people are doing, focus the discussion on the status of the story cards. You only need to talk about the stories that deserve attention. If a story is progressing as expected, don't spend time on it. By focusing on the stories, there is no obligation for everyone to speak at the standup. If you are pair programming, at most only half the developers need to talk.
Change the Purpose of the Standup
For many, the standup is a status meeting. It doesn't have to be. Many lean agile teams find their standup to be more focused on the flow of stories rather than the status. The questions in standup revolve around how to get the current cards to flow faster which is essentially Scrum question three. A colleague of mine, Matt Philip, has written a nice blog on this topic.
For teams that practice pair programming, changing pairs frequently, the standup can become a time to change pairs, assigning developers to stories and making sure that the assignments still make sense. More on that later.
Change the Time of the Standup
It is typical to have the standup first thing in the morning. This is a good opportunity to organize the team for the day. However, depending on your team culture, this may not be a good fit and is certainly not required. A team that has loose working hours may find a mid-afternoon standup works better, when the entire team is available.
Change the Mechanics of the Standup
Sometimes, how you hold the standup can affect how effective it is. Experimenting with the mechanics of it may yield some unexpected results. For example, try focusing your standup on your scrum board or Kanban board rather than on people. Or maybe the other way around. As an experiment, I once asked a team to hold their standup without talking. It forced the team to figure out how to communicate through their information radiators rather than ephemerally through spoken voice.
Change the Frequency of the Standup
I just learned of a team that decided that, since they change programming pairs on the hour ever hour, they would have a mini-standup on the hour every hour. Other teams may decide they only need a standup every couple of days. Teams that encounter change at a slower pace may decide to have one less frequently than daily. Although if this is the case, you may want to ask why.
The 5 Minute Standup
One of the reasons that standups go on for too long is that the team gets distracted by less relevant topics. It is important that the entire team understands that the purpose of the standup is not a large, in-depth knowledge transfer session. It is a quick, how are we doing and let's make sure we're organized session.
A couple of expressions that are helpful are "Great conversation. Not the right time to have it." And "ELMO," as in "Enough. Let's move on." Be warned that using "ELMO" can lead to many small fuzzy red creatures appearing in your work area.
Another useful trick is to have a parking lot area for discussions that are important but not for the standup. You may decide to have another discussion right after the standup to discuss one or more of those topics but you do that because the team has made a willful decision that it is important to have those discussions right now.
Another valuable tool is to use the standup to quickly set a daily goal. Setting a goal in the standup can help focus the discussion and keep out distractions. Goals should be aligned with the team's priorities. A goal may be something as obvious as "Let's get this many stories done today." Or something that might lead to positive behavior changes like "Let's have zero breaks in our automated build today."
The five minute standup is eminently achievable even with large teams. I've seen a team of 25 have a very effective standup in two minutes. They knew what they were there for. They had a procedure for how they proceeded through the standup. And most important, they knew when they were done.
But if a five minute standup is good and a two minute standup is better, why have a standup at all? We'll talk about that next time.
Dr. Mark Balbes serves as Vice President, Architecture at WWT Asynchrony Labs, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.