The Daily Scrum - Starting with Scrum Chapter 5

This is the fifth article in the Starting with Scrum series. In the first article, we discussed how to get started with Scrum by determining what the Product Goal is. In the second article, we talked about how to translate the Product Goal into a backlog. In the third, we looked at Product Backlog Refinement. In the last article, we started the first Sprint with the Sprint Planning.

In this article, we discuss the one event that happens every single day of the Sprint and which helps us manage the Sprint.

What is the Daily Scrum?

The Daily Scrum is all about checking the plan we made during Sprint Planning — making sure we are still in business. 

“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.”

Simple enough that to get the team used to the event I will usually just ask them one simple question: “Are we going to make it to deliver the Sprint Goal?”

At the beginning of the Sprint, confident in the plan they made in the Sprint Planning, this question will make little impression. But towards the end of the Sprint, as the team runs into surprises and unexpected challenges, and as team members get caught up in their work and lose sight of the bigger picture, it will gradually get more and more interesting. It becomes invaluable in helping the team keep their focus on the Sprint Goal and on making difficult choices.

This is a question of human nature. Ideally, programming is a game, a puzzle, and like any puzzle, it will eventually get solved. It is all a question of time. The very motivation that makes us good at our work makes it hard to stop playing. It is in our nature as developers to not give up. 

This is of course a great way of looking at our work, but at the same time, it poses a threat. With my teams, we call it “tunnel vision” — the tendency to get so absorbed in your work that you end up going down the rabbit hole and getting lost, forgetting everything else. Until, in the worst case, you are shaken awake by the impending end of the Sprint, but too late to refocus back on the higher purpose — the goal of the Sprint.

Focus is actually a double-edged sword. Too little and you can forget about flow. Too much, however, and you lose sight of what matters.

Like I said, this is human nature. It happens to us all, even the most senior developers. It takes great discipline to avoid it, and usually that acquired discipline is something similar to a Daily Scrum. One of the most common ones is starting the day going through your to-dos.

That is for me one of the main purposes of the Daily Scrum, to keep us sharp on that higher purpose. It serves to remind us to take a step back, enough that we remember what it was all about. The keyword is “Sprint Goal.”

Getting back to the end of the Sprint, when the Daily Scrum gets more interesting, I find that the tweaking of the plan laid out in Sprint Planning has a very strong effect on the team’s self-confidence. 

Even the best laid-out plans will get messed up, more often than not. That is the whole reason we adopt Scrum. And Scrum is not meant as a way to somehow avoid or mitigate this, but as a way to embrace it. And by embrace, I mean with enthusiasm as if it was your best friend! 

This takes a lot of confidence. And that is where the Daily Scrum comes in. It is a daily opportunity to discover how good we are at dealing with the unexpected and build that confidence.

You can kind of see a team evolving to a situation where the Daily Scrum becomes the most important event, taking on aspects of other events. Why wait until the Retrospective to tweak the process? Why spend so much time in Sprint Planning if you are going to be tweaking the plan daily anyway?

Conclusion

What I find most intriguing about the Daily Scrum is that it is a valuable event, whether you have an effective Sprint Goal or not. I have witnessed real collaboration, camaraderie and shared purpose in Scrum Teams working without a Sprint Goal. These are teams that work as a well-oiled machine, using the time to clear the slate, synchronise and plan until the next day.

I have come to suspect that the secret ingredient is ownership. A team with ownership has a goal, even if it is just getting all the items on the Sprint Backlog done. Even just helping each other can be a goal that brings a team together.

A Scrum team that does not take ownership of its work and its process and its purpose does not have anything to bring it together. It cannot embrace the single-mindedness needed to use the Daily Scrum effectively. This is where the event becomes a ritual, a status report where developers, having no idea what is expected of them, fall back on informing each other of progress. The good old what-did-you-do-yesterday, what-will-you-do-today and do-you-have-any-impediments is a relief, as it gives them a script to fill the 15 minutes of the event.

To me it seems that where the Sprint Goal may be the most important focus of a Scrum team to deliver value, ownership is the most important focus to create collaboration. A team guided by a single-minded drive.