Now that we’ve examined the history of daily scrum, we can shed some light on common anti-patterns of the event. Many of these are relics from Scrum Guides past: like scrum, the Guide inspects and adapts for continuous improvement. In other words, if you’re still following practices from an older Scrum Guide, you may be doing your team a disservice.
If you want to have a daily scrum that is a valuable planning event for your team, here’s what to avoid (and what to do instead):
Sticking To The Three Questions
“I’m blocked by…”
Please. That is so 2010.
In all seriousness, if your daily scrums consist of going around the room and everyone following this script, not only are they feeling stale, you’re not getting the information you need from the team. “The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.” (Scrum Guide) It’s not about what each individual on the team is doing, it’s about what the team collectively has done and will do to achieve the sprint goal.
I coach teams to start with this: “Our Sprint Goal is X. What do we need to do to achieve it?” Then it’s up to the developers to synchronize on their progress and come up with a plan of work for the day.
Daily Scrum As A Status Update
Whether you’re using the three questions or any other structure that focuses on the work of the individuals rather than the goal of the team, you risk losing the value of daily scrum as a planning event by turning it into a status update meeting. What’s the easiest way to tell your daily scrum has slid into status territory? There are no interactions among team members. Everyone is just waiting for their turn to speak.
The intention of daily scrum is to plan, not to update. Developers should be collaborating on what to do together as a team. You should hear questions, requests for help, offers to help, banter, and even some challenges on what to do next.
One baby step on the way from “me” to “we” in daily scrums is “walking the board.” Using the sprint backlog, go through each story going in order starting from closest to done to not yet started and ask the team what needs to happen to get it to done. As the team discusses the work, ask who else can help to get the work done. The team will slowly start to shift from a mentality of “my” work to “our” work and become comfortable teaming up to help rather than working as individuals.
The Scrum Master Facilitates
“The Scrum Master serves the Scrum Team… [by] ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.” (Scrum Guide) Nowhere in the scrum master’s accountabilities or in any of the events does it say that the scrum master must facilitate – or even attend – the scrum events. The scrum master’s highest value to the team is in coaching them to be self-managing. So if the team is relying on the scrum master to lead every daily scrum, the scrum master is failing the team.
The daily scrum is for the developers of the team. They get to choose what it looks like. And they get to run it. If the scrum master happens to also be a developer on the team, the scrum master can participate as such.
If you are a scrum master who is facilitating daily scrums, it’s time to stop. Let the developers know that this is their time to sync on progress towards the sprint goal and plan their work, and leave that to them.
The Product Owner Assigns Work
I have seen teams use daily scrums as a time for the product owner to assign work to developers of the team. Out of all anti-patterns we’re talking about, this is the one I find the most simultaneously heartbreaking and infuriating. If this is happening on your team, you have no right to say that you are doing anything remotely close to agile or scrum.
Not only does this anti-pattern defy the purpose of daily scrum, which is for developers to plan their work, it defies the value of self-management at the heart of scrum, defiles the role of a product owner into a team dictator, and stabs a scalding hot poker into the heart of worker autonomy and therefore team and individual motivation.
I could go on, but I will just say this. Don’t do this. Not at daily scrum. Not ever.
It Goes Longer Than 15 Minutes
I block out a 30 minute calendar invite for daily scrum. The first 15 minutes is for the daily scrum event where, as a team, we synchronize our progress towards the sprint goal and plan our work.
The second 15 minutes, or however long people want to stick around for, is for further discussion. This is anything that comes up during the daily scrum: if someone asks for help in looking at a bug. if there’s a question about a tool, if the team wants to nerd out about audio equipment (I work with a lot of audio technology teams). Whatever it is that is not part of the daily scrum gets called out as an “offline topic,” “off-scrum,” “afterparty”; the name is up to the team. If the team is remote, I encourage people to put their topics into chat for people to see.
I keep an eye on the time. At the end of 15 minutes, everyone is welcome to leave. I make a big deal of this. “That is the end of our daily scrum. If you would like to head out, please feel free. I encourage you to do so. Just head on out. Leave now or at any time.” And then I say, “If you’d like to stick around, we’ll be talking about…” and I refer to the list in chat, or have team members bring up what they’d like to talk about.
I also find it key to leave once daily scrum is over, before the afterparty, to demonstrate the behavior that it is OK to do so. That is, if I’m even at daily scrum as a scrum master.
In short, if your daily scrum is anything other than a planning event for developers, the people doing the work, it’s time to inspect and adapt your daily scrum. Need some help? Contact Agile Learning Labs to help coach your teams on positive, productive daily scrums.