The purpose of a Daily Scrum (also known as the daily stand-up) is to inspect and adapt the plan for a Sprint on a daily basis by coming up with a plan for the next 24 hours that will allow the team to complete their Sprint goal by the end of the Sprint. Sounds simple, right? But like everything else in Scrum, just because it sounds simple doesn’t mean it’s easy to execute well. Here are just a few things I have seen teams struggle with during Daily Scrums:
- Focusing too much on tasks and forgetting about the backlog items they’re trying to complete
- Talking over each other
- Diving into too many technical details
- Problem solving instead of identifying the problems to be solved
- Not asking team members if they need help when they didn’t complete what they said they would
When I was a developer on Scrum Teams, I knew it was my responsibility (along with everyone else on the team) to ensure that we accomplished the purpose of the Daily Scrum. As a new full-time Scrum Master, I expected members of the Development Team to do the same thing. When that didn’t happen, I struggled to find a way to teach the team how to effectively run the Daily Scrum themselves without having me facilitate it for them every day.
I know some people might be wondering why I, as a Scrum Master, don’t want to facilitate the Daily Scrum every day. There are multiple reasons, but the most important is that I believe for a Scrum Team to be resiliently productive, they cannot be overly reliant on one individual for anything. If a Scrum Master is always the de facto facilitator, what happens when he or she isn’t there? Typically teams will struggle because there is a hole that the team isn’t accustomed to filling. I have seen Scrum Masters facilitate the Daily Scrum every single day and then wonder why their teams don’t hold Daily Scrums when they are out of the office. I avoid this by not being the de facto facilitator.
Searching for a Solution
I needed to find a solution that would teach the team what a good Daily Scrum looked like without having to facilitate it every day. At first I tried facilitating every other Daily Scrum. Then I tried having the team rotate the facilitator role among every team member each day so that everyone would be comfortable with it. Although those experiments helped, they did not get the results for which I was hoping.
While I was reading the “Coach as a Facilitator” chapter of Lyssa Adkin’s Coaching Agile Teams, I came across her goals for stand-ups:
- Peer pressure
- Fine-grain coordination
- Focusing on the few
- Daily commitment
- Raising impediments
Although those goals are things I already knew, I had a difficult time teaching the team to practice them. When I came across Lyssa’s list, I had an idea that I thought just might work. The next morning at work, I grabbed some sharpies and a pad of ginormous stickies and went to work.
I added a few goals to Lyssa’s list, added some quantifiable metrics for determining whether those goals had been met, and hung them next to the Sprint Backlog on the wall. I introduced the chart during the Daily Scrum and told the team that we would be using it to inspect our Daily Scrum for the next week. Here’s how we did it:
- Immediately following the Daily Scrum, we did the assessment.
- Starting with goal #1 on the list, the team did fist of five voting to measure their execution of that goal.
- I summed all of the votes, divided them by the number of people voting, and placed a small sticky labeled with the current day of the Sprint on the line for that goal to indicate the average of the team’s votes.
- We repeated this process until we measured all of the goals.
On the first day this exercise took about five minutes because the team had to learn the goals as well as what a vote of 1 looked like as opposed to a 5. By the third day, we did this entire exercise in less than 90 seconds, so this technique is a very quick way to have the team inspect how they executed the Daily Scrum.
Starting on day one of the experiment, there was a dramatic shift in the team’s self-awareness during the Daily Scrum. By day two, team members were using the goal numbers to call people out on bad behavior. By day five, the Daily Scrums looked dramatically different than they did a week ago. Although there was still room for improvement, the team was accomplishing the goals of the Daily Scrum. I asked the team if they wanted to continue assessing themselves after the Daily Scrum, and they said that they understood the goals well enough that we didn’t need to continue.
I was curious to see how this experiment would affect the team’s behavior beyond the first week. I had taught the team what an effective Daily Scrum looked like. Now it was up to them to decide if they wanted to continue the practices they had learned.
Unfortunately, a month later the Daily Scrums looked much like they did before the experiment. Although the team knew what to do, they still struggled actually doing it. At this point, I began to understand that the problem wasn’t the Daily Scrum but the underlying attitudes and behaviors of the team. They were struggling with the Five Dysfunctions of a Team.
I concluded that the experiment was successful even though it didn’t result in long term change. It revealed a deeper problem on the team and gave me a new direction to begin experimenting with.