The Agile Architect
Making the Agile Standup Obsolete
A standup meeting is supposed to be an effective way to have a quick, meaningful team meeting, yet it is routinely despised as being too long and a waste of time. And it can indeed be a waste of time. Our Agile Architect explains why you might just not need a standup.
In my previous column, "The Agile 5 Minute Daily Standup," we discussed how to make a daily standup meeting effective yet still keep it under 5 minutes. This, of course, begs the question of if the team can get the standup meeting down to 5 minutes, then why have a standup meeting at all?
It's a great question, and one that was posed to me recently by a colleague. His team had abandoned their standup, not because they didn't want to do it, but because they had outgrown it.
Reasons To Meet/Other Means of Team Coordination
There are many reasons that teams have standup meetings, some dictated by the agile methodology that the team chooses to use, some decided by the team. But at its core the standup meeting is a fixed-time team coordination meeting, sharing important status and allowing the team to step away from the battle of software development to ask if they should be doing something different, or more, or less.
Let's attack some of the reasons teams have standup meetings head on and discuss alternate ways these same goals can be accomplished:
1. Share What Happened Yesterday
This is the first of the three Scrum questions. If the team is constantly collaborating, they probably already know this. During the work day, the team can constantly update each other through other means. Many teams have some kind of board, like a Scrum board or Kanban board, that they keep up to date. Pair programming naturally causes information to be shared as the pairs change throughout the day. Teams that have a low barrier to call for a quick, ad hoc team discussion on a specific topic tend to have more awareness of what each other is doing. Big, visible information radiators like burn up charts and cumulative flow diagrams lets the team have constant awareness of their cumulative efforts.
2. Share What You Are Going To Do Today
Teams that work with a team board, a prioritized backlog and defined working agreements can easily determine the work that will be done that day. On an agile team, it is not important who is doing the work but that the work is getting done. Therefore, the question "What am I going to do today?" is irrelevant. The real question is, "What is the team going to do today?" The answer is simple. They are going to work through their prioritized backlog of small stories per their process as defined in their team charter and team working agreements.
3. What Is Getting in Your Way?
If something is getting in your way, why would you wait until the standup meeting to bring it up? Often the things getting in the team's way, sometimes called blockers, that are brought up at standup are either long-lived issues that everyone already knows about or are the smaller blockers that just happened to come up right before standup. Other small blockers that come up during the day are handled in the moment. Blockers can live on interminably, even to the point where everybody groans and they get ignored at the standup. By having a visible process for monitoring and mitigating blockers, the team can more effectively manage them and remove the discussion from the standup.
4. Bring the Product Owner and Others Up to Speed
Standups can be an effective way to bring people up to speed who may not be around for all the ad hoc discussions, pair switching and other activities that go on in the war room. The product owner, agile coach, and scrum master (or equivalent) may spend significant time interacting with other people in the organization. If the team is making decisions and taking action in the moment, there needs to be a way to catch up. But again, why would you wait for a standup to do this? There's nothing wrong with a long-absent team member, after checking the status of the team boards and other information radiators, from asking the team, "What did I miss?" And this, in and of itself, acts as an opportunity for the team to collectively take a step back and review what they've done.
5. Pair Switch
Teams that practice pair programming may use the standup meeting as an opportunity to switch pairs. In fact, I've seen teams where that is the only reason for the standup. But creating a trigger for pair switching can be done more effectively through team working agreements that call for a pair switch at certain defined points in the development process. For example, suppose that your development process calls for three steps, test driven development, review, final testing. In a Kanban process these might be columns on your Kanban board. The team could have a working agreement that they pair switch when a story moves from development to review. This will force a switch between at least two pairs of developer. When the story moves from review to final testing, the team might have a working agreement that one of the developers in the review pair will pair with a QA engineer to test the story against the acceptance criteria.
A Method for Eliminating the Standup
You may never be able to get rid of your standup meeting but making the attempt may bring great benefits. Start the process by figuring out the purpose of your team's standup: I've mentioned several above, but that doesn't mean that's why your team has one. Once you have concretely defined its purpose, use your retrospective as an opportunity to decide on an experiment to try to eliminate just one of those things. If that doesn't work, try something else. Repeat until there is no reason to have a standup meeting.
While it may seem like it, I'm not trying to convince you to abandon your standup meeting. There is a different dynamic when the whole team comes together. Topics are discussed that aren't in one-on-one or less formalized team discussions. Not having a standup may be a missed opportunity for a necessary team discussion that just wouldn't happen spontaneously. In the end, it's up to the team to evaluate how to get the most out of the standup meeting and when it provides diminishing returns.
Dr. Mark Balbes serves as Vice President, Architecture at WWT Application Services, 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.