Years ago, in the bad old days, you had the weekly status meeting. You'd wait for your turn to talk about your status to the project manager; when other people talked, you'd either tune out to think about what you were going to say or, possibly, tune out entirely and think about that upcoming skiing trip.
All that changed with scrum and the daily standup. It was a breath of fresh air.
But something happened with the daily standup in many organizations. As its focus changed, people were driven to prepare a list of what they were working on and to focus on it.
[ Analysis: Has Agile Software Development Gone Mainstream? ]
I woke up one morning and realized that, at a current client, we were still doing those painful, low-value weekly status meetings. The only difference: Now we were doing them every day.
If you've experienced this, take heart. You're not alone. More importantly, the daily standup can be fixed. This article explains how.
Answer Me These Questions 3
First, let's look at the famous Three Questions of Scrum:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
Now, adopt the mindset of a command-and-control project manager. Read those words again. Turn your head sideways and squint. Sounds a bit like a status report, doesn't it?
The first book to describe Scrum, Wicked Problems, Righteous Solutions, did it thusly. You'll notice that the three questions don't appear.
Suppose you have a software development project to do. For each traditional phase, you can draw from a pool of experienced people. Rather than have several designers do the design phase and have several coders do the construction phase, etc., you form a team by carefully selecting one person from each pool. During a team meeting, you will tell them that they have each been carefully chosen to do a project that is very important to the company, country, organization or whatever. This unsettles them somewhat. You then give them a description of the problem to be solved, the figures for how much it costs in time and money to do similar projects and what the performance figures for those systems are. Then, after you have gotten them used to the idea that they are special, having been specifically chosen to do an important job, you further unsettle the team by saying that their job is to produce the system in, say, half the time and money and it must have twice the performance of other systems. Next, you say that how they do it is their business. Your business is to support them in getting resources. Then, you leave them alone.
You stand by to give them advice if you are asked. You get their reports, which come regularly but not as often nor as voluminously as the waterfall model. But, mostly you wait. In something like the appointed time, out pops the system with the performance and cost figures you want.
Sounds like a fairy tale, doesn't it?
Wicked Problems came out in 1990 and mentions scrum only in passing. The first paper on scrum, Scrum Development Process, published at OOPSLA in 1995, doesn't mention the three questions, either. Nor do they appear in the early Extreme Programming books by Addison-Wesley.
Asked about this question, Jeff Sutherland, a coauthor of that paper, says that the single greatest improvement from scrum at Easel Corp. was the daily standup meeting, and that the team used the three questions. However, he adds, "Teams have regularly misused the questions as status reporting."
Inspect, Adapt to Save Daily Standup Meeting
So Sutherland and coauthor Ken Schwaber rewrote them. The new questions, which appear on page 10 of the 2013 Scrum Guide, shift the discussion from exactly what the person did (and will do) to instead list the things that help the team accomplish the sprint goal.
First, determine if team candence supports daily meetings. If it does, then focus on the parts of the meeting that deliver value, not the ceremony of the meeting itself.
For Yuret, that meant suggesting that project status is obvious from the team progress board. Instead of focusing on tasks, Yuret changed the meetings to two questions:
- Does anyone need help?
- Does anyone have anything to talk about?
When Yuret implemented this new, leaner startup at a large retail company, the standup moved from 35 minutes to five. With a 10-person team, that's a net savings of five person-hours per day, which adds more than half a person of velocity per team.
Yuret's model of the standup isn't unique. Teams at Press Ganey Associates have used another approach, called "watching the flow," for the past several years. Here the team talks about each piece of work, or storying, while "walking the board." For each story in process, the people doing the work talk about what it will take to get the piece of work to the next stage, when that should happen and if the programmer or tester needs help.
[ Related: How Story Mapping Complements Agile Development ]
This method uncovers work that isn't advancing, as no one answers when the story is mentioned. If the facilitator is paying attention, he or she also notices who doesn't speak up and asks about the off-board work that person is doing and, therefore, might need to be visualized on the board.
While the Press Ganey teams periodically inspect and adapt, they left the three questions behind in 2011 and haven't looked back.
Socialtext went through a similar change to daily standup meetings from 2008 to 2011. With a physically distributed team, the group focused on eliminating blocking conditions during the work day, not waiting to discuss them in standups. The team also used a wiki to document answers to the three questions before the meeting, leading to a faster standup. Eventually the standup focused more on accelerating and splitting up the days' work, not on current status.
Add Value Without Adding Drag
The daily scrum was supposed to get away from status and toward accelerating the team. Watch the flow, focus on value, find out who needs help — all these methods add value without adding drag.
If you see drag in your standup, you might consider dropping it. That might be appropriate. But before you do, consider adjusting the standup questions — or letting go them — and rebooting the process.
If that sounds scary, just bring it up at the end of the sprint, as an experiment. Something to try for the next week or two and adjust as needed.
Who knows? Your team may just thank you for it.
Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.