Picture a team standing together in front of a wall full of lines and post-its. They have what they call a "Daily Scrum." It's a daily, 15-minutes meeting that happens 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. I have no problems to report 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 almost completed it. No real problem, but if it takes more than 30 minutes, I'll ask for help.

Was that the perfect Daily Scrum?

By all means, this daily was excellent. The statements were short and crisp. They followed the pattern the (2017) 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 the Development Team or me 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. So was 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. In-fact, the 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 three questions? The "walk the board" format goes like this:

  • We remind ourselves of the Sprint Goal and ask ourselves if we are on track to reaching it.
  • Then consider the first Story only. 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 what is in the "To-do" column. Create a battle plan to complete this Story.
  • Everyone should now know the state of the first Story. Expectations are aligned, and everybody knows what the plan for the day to come is.
  • If there is any need for further discussions, we mark them and postpone them.
  • If we have the feeling that the day is full, we stop right there and do not talk about the next Story.
  • Suppose 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 for the next 24 hours. Then we look at our overall progress again:

  • We remind ourselves of the Sprint Goal and ask ourselves if we are on track to reaching it.
  • If needed, we briefly talk about more than the 24 hours time-horizon. Particularly about measures required to finish the most important stories.
  • I like to close the daily by summarizing what we learned and significant next steps.

We didn't do any reporting. Instead, we collaborated to solve a complex problem. Doesn't this sound way more rewarding?

You might be asking yourself:

  • But how do I make sure that everyone spoke?
  • How do I make sure that Leeroy doesn't spend his time playing during the day and hiding during the Daily Scrum?

I must answer with questions because your problem is elsewhere:

  • Why do you need everyone to speak? If a teammate is regularly suppressing someone else's voice or is shy, you need to facilitate the exchange, not enforce speaking-time.
  • Let's assume Leeroy is indeed playing the whole day. Does twisting his arm during the Daily Scrum by forcing him to speak solves the problem?

How did we end up there?

What does the Scrum Guide say about this?

Version 2017 of the Scrum Guide contained the following:

The meeting structure 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:
1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to support the Development Team reach the Sprint Goal?
3. Do I see any impediment that prevents the Development Team or me 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.

This formulation is ambiguous. It allows for both interpretations; a people-centered and a product-centered one, which is fine. But it primes the reader to follow this exact example, and this is not.

No wonder new Scrum Masters pick this idea and propagate a people-centered way. Command-and-control structures are still legion in our industry. We are used to busyness and 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. And I weight my words. I regularly read Tweets and hear comments from people dreading their Daily Scrums and running away from Scrum, just because of this reporting.

Instead, we desire teams to increase their focus and work on fewer stories. We long for lower work in progress, more swarming, and pair- or mob-programming. We want more strategic and tactic exchange. We wish to see more trust, teamwork, and problem-solving.

And here is where we go full circle. Doing exactly so, mature teams will fall back on the three questions but without reporting. From this point of view, the 2017 Scrum Guide makes a lot of sense. But not for less mature teams. And that is probably why the authors changed the Daily Scrum part of the guide in the 2020 version.

They heavily trimmed the Daily Scrum part (from 2200 to 1000 characters). They removed the questions and reformulated the above paragraph as follows:

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

This new formulation weighs heavily on the focus and progress side. I like this. With this new Scrum Guide, and with more Scrum Masters understanding the "Walk the Board" approach, there is hope!


Photo by 襤rfan Simsar on Unsplash