Picture a team standing together in front of a wall full of lines and post-its. They’re having what they call a "Daily Scrum". It’s a daily, 15-minutes meeting that happen among Scrum teams.
And it could go like this:
Bob: Yesterday I worked on Story A, I fixed this and that. And now I am busy getting this done. No problems so far. All is fine!
Mary: Last evening I coded this task for Story B. I had massive concurrency problems with component X, but it’s resolved. If you face this problem, pay attention to the “Covfefe”. That’s the key. I started with this task and could need some help in setting up the load test.
Lisa: Until noon yesterday I worked on Story A. I implemented this task and reviewed that one. I noticed a recurring problem with component Y and talked to Josh about it. Then I switched over to Story B and started this task. I’m not quite done. No real problem but if I’m not done in 30 minutes I’ll ask for help.
Isn't this the perfect Daily Scrum?
By all standards, this daily was great. The statements were short and crisp. They followed the pattern the Scrum Guide recommends. That is answering those three questions:
1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The team members added useful information about the problem they faced. They brushed over the solutions they found. Lisa even set up expectations by giving a deadline.
Is that the perfect Daily Scrum? I don’t think so.
Yes, each team member answered the infamous “3 questions” of the Daily Scrum. But the focus was all over the place. Everybody talked, but they jumped from one topic to the next. The whole team did 15 minutes of reporting-context-swapping.
As a Scrum Master, at the end of such a Daily Scrum, I wouldn't be sure that we are all on the same page. I would recapitulate the priorities. I would ask for a summary of what is ahead of us and align expectations. I would steer away from a people-centered daily-Scrum to a product-centered one.
Walk the board instead
Do we need the first part of that Daily Scrum? What if the team focused on the product in the first place instead of focusing on the 3 questions? This is the “walk the board” format and it goes like this.
- Start by looking at the first Story only and there, focus on the work in the "Done" column first. Every person that has something to say should jump in.
- Then talk about the tasks that are “in progress”. Again, anyone involved can add something.
- Finally look over at what is in the “To-do” column. Create a battle plan to complete this story.
- The story should now be clear. You should know everything there is to know at that moment. You should have aligned expectations and a plan for the day to come.
- If we have the feeling that the day full, we stop right there and do not talk about the next story.
- Or we have a good reason to continue. We would then do the same for the next story. Rinse and repeat.
At the end of this process, we have a clear idea of the battle plan to finish the most important stories. We have a clear idea of how the next 8 hours should go. We didn't do any reporting. Instead, we collaborated to solve a complex problem. Doesn't this sound way more rewarding?
But how do I make sure that everyone spoke? How do I make sure that Kevin doesn't spend his time playing during the day and hiding during the Daily Scrum? The answer is in the question. We do not want reporting, we want teamwork. If you need this, your problem is not in the Daily Scrum, it is elsewhere.
How did we end up there?
What does the Scrum Guide say about this?
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The formulation is ambiguous. I see how both interpretations can emerge, one people-centered and the other product-centered. Why do people often choose and propagate the people-centered one? I can only speculate. I guess it has to do with the command-and-control structures that are still legion in our industry. We are still used to busyness. We are still used to reporting. We are still used to focus on individual performance instead of teamwork. And thus, we propagate this way of viewing the Daily Scrum, fucking up one team after the other.
But wait, there is hope. When teams mature, they will increase their focus and work on less stories. They will lower their work in progress (the number of tasks they tackle at a given time). They will swarm (work together to finish stuff). They will pair- or mob-program. They will trust each other. They will orchestrate well. And doing so, they will stop reporting and start problem solving. Focusing on those 3 questions is inherently right. Because when mature teams focus on those questions, they are automagically walking the board!