The Daily Scrum is an often loathed Scrum practice. But it certainly wasn’t invented to waste your team’s time – so what are we missing? Why are some teams not getting value out of the Daily Scrum? And most important: How do we do better?
Let’s start by looking at a typical “Daily Scrum” as I’ve seen it unfold countless times.
That‘s not a Daily Scrum
Here‘s what I often see – and it hurts my soul. Because that‘s definitely not a Daily Scrum, no matter how many times people call it “Daily Scrum“.
The Scrum Master calls for the Daily and the developers begrudgingly trott to the inevitable. You can hear a few moans here and there about interrupting their work.
Now the team stands in a semi-circle, the Scrum Master turns to face the first unlucky developer and pops the big question:
“What have you done yesterday?“
The developer, who dutifully prepared for this, replies with a list of tasks in a monotone voice. None of the other developers is listening or even knows what he‘s talking about.
The Scrum Master thanks him and asks the next two questions: “What are you gonna do today?“ and “Do you have any impediments?“. To the last question the developer just replies “no“ even before the SM finished phrasing the question.
Now the Scrum Master turns to the next developer, asking the same three questions. Again, they‘re answered in monotone without any of the other developers paying much attention, let alone getting any new information or value out of the ceremony.
When the show is over, the Scrum Master thanks the whole crew and dismisses them. With a sigh of relief, the developers can finally “go back to work“.
What was the value of this session?
Many Daily Scrums feel like a brain-dead status report. Nothing could be further from the intention of Scrum.
Why the Daily Scrum exists
I don’t know about you, but I find it hard to see any value in the scenario I just described.
So why do so many teams‘ Daily Scrums look a lot like this scenario? The reasons ange from the mechanical application of Scrum without understand it to deeply ingrained management structures from pre-agile times.
The thing is: Whatever excuse one might find to justify the above scenario, this kind of “Daily Scrum“ has absolutely no value!
If the Scrum Master or PO need to know the status, they can just look at the Sprint Backlog; if managers need to check if people are actually working, they‘d better reconsider their hiring descisions.
So should be skip the Daily Scrum? Is it another useless meeting? No, we‘d better understand what the Daily Scrum is REALLY for.
The purpose of the Daily Scrum can be outlined as this: – Allow developers to plan collaboration for the day – Avoid other meetings – Check whether the Sprint Goal is still in reach – adjust if necessary – Avoid interruptions throughout the day – Help each other as a team
I want to point out two corollaries with this:
- It‘s not a status report
- The Daily Scrum is by the developers, for the developers. Nobody outside the Scrum Team is interested in it.
The common misunderstanding
Traditional management styles often rely on status report to know what‘s going on. They lack the transparency of an agile approach.
Traditional management styles also tend to control employees quite tightly. The assumption often is that if you don‘t check what people are doing, they either do the wrong stuff or nothing at all. The root is a fundamental mistrust rooted in their view of the human being in general. Traditional management structures often subscribe to the thinking that people are extrinsically motivated by incentives and/or punishment.
But since the 1950s we know how strong a force intrinsic motivation is in the work place. We know that trying to “bribe“ (aka incentivize) people via bonuses, promotions or other means is actually causing lower performance in knowledge work.
And because of the transparency and short iterations, the status of work if much more visible than in non-agile environments.
So a reporting of the status to make sure people actually work hard and to know what‘s going on is not needed.
The question is: How can we get from bad Daily Scrum to good Daily Scrums?
How you can improve
For such a short Scrum event like the Daily Scrum, there are surprisingly many things you can do to improve it. As it‘s too much for a single article, I wrote an entire book about it.
Here are a few examples how to improve your Daily Scrums:
Remind the developers to talk TO EACH OTHER.
Whenever a developer starts talking to the Scrum Master, remind them that their fellow developers should get vallue out of what is said. If they finished something so that a team mate can pick it up from there, they should address that team mate. If they have a problem, they should ask their team mates for support. If they plan to implement something today, they should face their teammates to see who can pair with them.
Take the Scrum Master out.
While the Scrum Master can support the Daily Scrum and pick up crucial impediments, they‘re by no means the centerpiece of the action. If they are, it can be a good idea to take the SM out.
Just don‘t start the Daily Scrum and let the developers do it on their own. Stay away as a Scrum Master and watch how they developers teact. Don‘t ask the 3 questions or otherwise make yourself the centerpiece of the action as an SM.
Have Sprint Goals.
When a team has a common goal, they will support each other and collaborate to reach that goal. But if everybody on the team has their own separate todo list, you don‘t have a Scrum Team. A Daily Scrum as a collaboration sync of the developers kinda only makes sense, if they all work towards a common goal.
These were just 3 tiny examples. My book The Daily Scrum is Not a Status Meeting has a lot more to really improve your Daily Scrums.
What a better Daily Scrum looks like
With the above advice, a better Daily Scrum might looks like this:
The developers get together on their own – no Scrum Master needed. One developer starts and tells that they got stuck on user story they tried to finish yesterday. Another developer immediately offers help. She asks her colleague if they should get together after lunch to solve it. The first developer has his deep work time in the afternoon, so they quickly agree on 10am for their joined session. A third developer chips in to pick up the next important user story, so that they still reach the Sprint Goal, even though the first developer is blocked. The give each other a high five and start into their productive day.
Notice how the Scrum Master isn‘t the centerpiece anymore. The developers sync among each other and try to achieve the common Sprint Goal. They quickly plan their day and collaboration activities. This ensures that one developer isn‘t interrupted in his deep work time and keeps productivity high.
Conclusion
They Daily Scrum is often misunderstood as a kind of status report meeting. That totally voids the value of this Scrum event. Understanding that the Daily Scrum is by the developers and for the developers changes the perspective. Embracing this notion together with a general agile view of the human being paves the way to Daily Scrums that are a net positive for the team, the product and the customer.
Hit reply and tell me your experiences with Daily Scrums so far!
And just for fun, here are a few more of my memes about the Daily Scrum 😆
Again, hit reply and tell me your experiences with Daily Scrums so far!
Thank you for reading The Agile Compass. I’m Matthias, here to help you help those around you become agile.
To get more, consider upgrading to a paid subscription. You’ll join our Discord community and get access to all past articles.