Does Scrum hold up to scrutiny? - The Daily Scrum
Does Scrum hold up to scrutiny? - The Daily Scrum
Chapter 10
I’m going through the complete Scrum Guide (2020 version) and turning it inside out. Hoping to find a satisfying answer to the question: “Does Scrum make sense?”
I started with “Purpose of Scrum” and “Empiricism”. I came to the conclusion that the premise of Scrum is sound. Then I looked into the Scrum Values, which can indeed bring the pillars of empiricism to life.
Then I discussed the Scrum Team. And I wondered how often a Scrum Team and its stakeholders work in an environment where all Scrum Values can be upheld, the team has no hierarchies and everyone understands the Scrum theory well enough to make effective use of the framework.
The fourth topic was the Developers, who should own the What, How, and When to achieve a Sprint Goal. And the last two weeks I wrote about my issues with the Product Owner and Scrum Master accountabilities and asked if they aren’t too prescriptive.
I am more positive about the Sprint and the Sprint Planning. I believe the Scrum Guide 2020 makes very clear how they serve empiricism. Let’s now see if they continue this with the Daily Scrum.
The premise of the Daily Scrum
The 2020 Scrum Guide starts the Daily Scrum section with a clear statement about why this event exists:
“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.” - Scrum Guide 2020
We again see the emphasis on the Sprint Goal. After all, this is the commitment of the Scrum Team. In fact, this quote underlines how the Sprint Backlog should be adapted when the Developers find better ways to reach the Sprint Goal. The writers of the Scrum Guide did a masterful job of removing descriptive elements while also being clearer on the main purpose of the Daily Scrum. The above quote says it all.
Who, when and what
The Daily Scrum is a 15-minute event. It is interesting to see how it isn’t time-boxed like other events are. It’s 15 minutes, not up to 15 minutes. This may seem like a nitpick, but I find it striking. It’s the only non-timeboxed Scrum event (apart from the container event the Sprint which also is of a fixed length).
It leaves me wondering why it wouldn’t be okay to finish a Daily Scrum in 10 minutes. Suppose the Developers confirm they are on target towards the Sprint Goal and have a clear idea of what to do the next day, why can’t they be done sooner?
The intended participants are the Developers, not the Product Owner and Scrum Master (unless they are Developers too). This underlines what we saw in the Sprint Planning section: the Developers own the Sprint Backlog. They determine what needs to be done, and how it needs to be done to achieve the Sprint Goal.
The next lines of the Scrum Guide confirm this: Developers can choose their own way to do the Daily Scrum. As long as the focus is on the Sprint Goal and the result is an actionable plan for the next day.
There’s no mistaking: the Scrum Team creates the Sprint Goal. This is the commitment for the Sprint. The Developers determine how they best can reach this Sprint Goal (by creating an Increment). This is firmly in line with the acknowledgement that with complex work, you can’t know exactly what you need to do to achieve your goal. And as the Developers do the work, they are the ones to assess their progress and adjust their plans.
It is interesting how the Scrum Guide mentions the Daily Scrum should make other meetings obsolete, but a sentence later acknowledges that Developers can adjust their plan throughout the day. I’d assume they would need meetings for this. Sure, they could also be a few sentences in a team app, but I find it a slippery slope nevertheless.
On top of that, I find it fascinating that the Scrum Guide needs to mention Developers are ALLOWED to adjust their plan outside of the Daily Scrum. I have an issue with this because we already established Developers are self-managing. So why should this mention of them being allowed to work in a certain way be there? I rather have something like: “The Daily Scrum is not the only time Developers may (or can) adjust their plan.”
The Daily Scrum section concludes to tell us Developers often meet throughout the day for more detailed discussions. This is probably meant to clarify that the Daily Scrum is not intended for these discussions. And probably also to highlight the importance of collaboration throughout the day. But it proves my point that the earlier statement of the Daily Scrum making other meetings obsolete is shaky at best.
Not for the Product Owner and Scrum Master?
The Daily Scrum is the event for the Developers. But what about the Product Owner and Scrum Master? Are they not allowed to participate? Well, unless they are Developers too, the Scrum Guide says they shouldn’t.
This doesn’t mean they aren’t allowed to attend the Daily Scrum as spectators to understand how the Developers progress with their work. The Scrum Guide is - as I see it - merely highlighting the importance of self-managing Developers. The exclusion of the Product Owner and Scrum Masters as participants aren’t to exclude them from the discussion. It is to empower the Developers.
I can also imagine the Scrum Master as a facilitator of the Daily Scrum when asked by the Developers. On top of that, the Scrum Master is responsible for a positive and productive Daily Scrum. This means that they need to find ways to assess this and help the Developers to improve.
As for the Product Owner, they collaborate with the Developers to discuss the scope of the work to achieve the Sprint Goal. I believe the Daily Scrum would be a great place for this discussion.
Therefore, I believe it may be a healthy situation for the entire Scrum Team to attend the Daily Scrum while understanding the Developers are in the driving seat during the discussion.
Verdict
As with the Sprint and the Sprint Planning, I am very happy with the premise of the Daily Scrum. I also like how clearly the Scrum Guide 2020 expresses the purpose of assessing progress towards the Sprint Goal and adjusting the Sprint Backlog if needed.
I also agree with the emphasis on the Developers. They do the work, so they should be in charge of planning and building the Increment to achieve the Sprint Goal.
I have some nitpicks. Why isn’t the Daily Scrum time-boxed like the other events? Why doesn’t the Scrum Guide express the potential role of the Product Owner and Scrum Master in the Daily Scrum? As it is now, the Daily Scrum section of the Scrum Guide is somewhat confusing and even seemingly contradicting. It requires a firm understanding of the Scrum framework to interpret these parts.
It would reduce complexity to make it a timeboxed event, like the others.
And while we're nitpicking anyway: we all agree that it should not exceed the 15 min. But at the same time, it can never be exactly 15 min, so it's a timebox by definition.
When the team is done sooner, they're done.