The daily Scrum meeting is both the most familiar and most misunderstood event in the Scrum framework. On the surface, it seems straightforward: Every day, the Developers meet for no more than 15 minutes to self-manage and self-organize their work towards completing their sprint backlog. But it turns out that this simple-sounding event is a […]
The daily Scrum meeting is both the most familiar and most misunderstood event in the Scrum framework. On the surface, it seems straightforward: Every day, the Developers meet for no more than 15 minutes to self-manage and self-organize their work towards completing their sprint backlog. But it turns out that this simple-sounding event is a magnet for anti-patterns that can derail a team’s ability to deliver value and own their continual improvement.
Consider this example:
ScrumMaster: Okay, everyone, time for the daily Scrum! Let’s all look at our Scrum board. Let’s start with Sue… Did you finish tasks #317 and #318 yesterday?
Developer Sue: Yes. Today I’m going work on task #320.
ScrumMaster: Great. I notice that you haven’t updated the status of those tasks in the board, so please fix that so the burndown chart looks right. Any impediments?
Developer Sue: No.
[ScrumMaster then repeats this pattern with 3 more team members]
ScrumMaster: Now let’s go to Sri.
Developer Sri: I’m still working on the thing from yesterday, and…
ScrumMaster: [ahem]…Three Questions, please…
Developer Sri: Sorry. Yesterday I didn’t finish task #286, today I will work on #286, and I have an impediment which is I can’t figure out why #286 doesn’t work.
ScrumMaster: Okay. Sue and Yao, can you help Sri figure what’s broken?
Developer Sue: Have you tried…
[the rest of the Scrum team stands around while Sri, Sue, and Yao problem solve for 20 minutes]
ScrumMaster: Sounds like we’re good! Great Scrum everybody. Let’s get to work!
If that script sounds familiar, keep reading, because that team is suffering under some misconceptions that are making this daily event mostly useless.
Who’s running the show in the example above? The Scrum Master. The Scrum Master is calling the team together to start the Scrum. The Scrum Master is directing the inputs, calling on team members one by one to report status back to the Scrum Master. The Scrum Master is dictating the form of the updates. The Scrum Master is directing team members to collaborate and help each other. The Scrum Master is deciding when the Scrum is over.
The problem here is that the daily Scrum belongs to the Developers. This meeting is supposed to be a short conversation between Developers to understand where we stand in terms of meeting our sprint goal, and a method of self-organizing and self-managing our work as a group. When a Scrum Master takes on the responsibility of running this event (whether intentionally or not), the team loses ownership of those critical behaviors, and they begin to work as if they are the employees of the Scrum Master who is functioning more as a manager of daily tasks than a coach of the team’s collective functioning and improvement.
Notice in the example that Sri begins to give their update in a conversational style, but the Scrum Master interrupts to remind them to stick to a particular format called the ‘3 Questions.’ In this method, each participant answers some form of the questions “what did you finish yesterday?,” what are you going to work on today?,” and “do you have any impediments?” This pattern was even referenced for many years in the Scrum guide, so it’s easy to see why many teams think it’s a requirement of Scrum. Unfortunately, I’ve worked with a lot of teams that are not well served by this format. And the reason for that is because it’s easy for a team to come together, have each person answer those questions into the air, and then go their separate ways for the rest of the day.
The Daily Scrum is best understood as a conversation about conversations. The point is that by end of this short discussion, every team member should understand who needs to talk to who about what today. If your team is using the 3 Questions format and it seems to be working for you, great! If it isn’t helping your team reach that shared understanding of today’s plan, you’re free to use any other method that seems appropriate.
One reason the Scrum Master in the example may have taken ownership of the team’s daily Scrum is that the Developers don’t see much point to the meeting and aren’t motivated to participate. That’s completely understandable given that their experience of the daily Scrum currently is just as a shared status update. They’re not talking to each other to self-manage the work of the sprint. They’re not self-organizing to solve problems and share knowledge. They’re not using the visibility of the Scrum meeting to support mutual accountability. Instead, for them, the event is just about accounting for your own individual behavior to the Scrum Master and then going back to your desk. That’s not very useful, and no one enjoys going through the motions of some behavior that doesn’t seem to have any benefit.
A properly functioning daily Scrum is an extremely efficient behavior. It’s about how the team will get the work done (self-management) and who will do which part of it (self-organization). By attending one 15-minute conversation, each person on the team gains a shared understanding of what the team is doing and how their work will fit within that pattern for the next day. And that’s the only meeting that most team members should need to go to in a day.
In the example above, a developer identifies that they’re stuck on a task, and then the Scrum Master directs two other team members to help them solve the problem. The three team members then spend 20 minutes debating the issue, until the Scrum Master decides the conversation is over and ends the daily Scrum. But what are all the other team members doing during that conversation? Standing around, wondering when they’ll be able to leave and go get some work done, apparently. That’s not a good use of any one’s time!
Extending the conversation about conversations notion, it’s not usually efficient to solve problems during the Scrum meeting. Instead, the goal is for the team to identify the problem, then understand it enough to decide who needs to be involved to solve it. At that point, just the relevant parties can meet offline to fix it. In the example, when Sri brought up being stuck, a better pattern would have been for other team members to ask one or two clarifying questions to understand the nature of the problem. Then, as a group they could decide who should collaborate outside of the Scrum meeting to resolve it (which might be a different answer than the Scrum Master’s choices).
One more problem visible in the example scenario above is the Scrum Master’s focus on updating status artifacts as a goal of the daily Scrum. Questions like “have you updated the status of the ticket you finished?” or “what task number are you working now?” are often an indication that our understanding of the work has been abstracted into a ticket-completion mentality, rather than focusing on delivering real value. When a developer in the example team says, “I finished tasks #317 and #318 yesterday,” does anyone else on the team actually know what those things are? What work are those items are a part of? Does that mean we’re closer to finishing something that supports the sprint goal? Those are the questions that really matter, and that a team should be able to understand based on their daily Scrum.
When the daily Scrum meeting is seen as being mostly about ticket completion and updating the sprint burndown chart, that’s a sign that team’s work has been siloed and divorced from the continual real-world feedback on impact that makes Agile deliver so powerful. If teams aren’t updating their self-organization tools (like a task board), they should take a hard look at why there doesn’t seem to be value for them to do so.
Don’t despair. There are a few immediate steps organizations and leaders can take to get out of these anti-patterns and support healthier Scrum.
Scrum is often described as ‘Easy to learn, hard to master.” That’s absolutely true! Many of the problems discussed here are easy traps to fall into as a new and inexperienced Scrum Master. Getting them more high-quality training like an Advanced-Certified ScrumMaster (A-CSM) course would be a great way to expand their skillset and compare practices with other people who’ve dealt with the same issues.
One of the most valuable services provided by a seasoned Agile coach is mentoring Scrum Masters and creating a path for organizations to grow and develop Scrum-Mastering as a career. Great Agile coaches can model key behaviors and teach core skills without undermining the position of your Scrum Masters and in a way that supports your teams’ ownership of their improvement. Learn more about Agile coaches.
Sometimes these behaviors are the result of outside pressure, as when an organization is used to focusing on task status and overlays that habit on a Scrum team. Training and nurturing Agile leadership can create an environment where managers and executives understand the best way to support Agile teams and Agile-based value delivery. Certified Agile Leadership training is a great place to start, and individual or cohort-based leadership coaching can help cement the practices and mindsets needed to get the most out of your Agile teams.
A Full Breakdown of the ScrumMaster Role
Put as simply as possible, Scrum is a methodology that helps teams work better together....
When the Scrum Master Role is Set Up to Be an Anti-Pattern
Sometimes an organization struggles to understand the value proposition of a Scrum Master. The role...
A Day in the Life of the Scrum Team
A client recently asked me, “Can you tell me what the members of the Scrum...