Change Your Daily Scrum Meeting

14 November 2013


This article tells the story of our experience implementing a shift in approach during daily Scrum meetings. We went from a typical approach centered on each individual to one centered on each story in the sprint backlog. The idea for such a shift was inspired by a Jeff Sutherland paper, one of those many great writings Jeff has produced throughout his career.

The goal is to briefly explain why and how the change was adopted, the strengths and weaknesses we observed, and feedback we were able to obtain upon having adopted the shift in approach. But, before launching into an explanation, it is important to provide you with the context of this experience.

Context

I have been an Agile coach for more than six years and have worked in various Latin American companies that develop software locally and internationally using Scrum. The clients of these companies have adopted Scrum and participate in daily Scrum meetings, assuming the role of product owner.

When and where did the need to change the daily Scrum meeting arise?

The change arose in the retrospective meetings of each team. Although we were active in three separate companies and in four different projects/teams, the experience that gave rise to the shift in approach was similar across all teams, projects, and companies.

Before adopting the change, the daily Scrum meeting was carried out in the standard way. Each team member would respond to the three classic questions: 1) What did I do yesterday? 2) What blockers did I have? 3) What am I going to do today? When a team member would finish their story, the next would continue. This would repeat itself until the round was complete. That is, the dynamic was focused on each developer having their time to speak.

After several months and dozens of sprints, many issues related to the inefficiency of the daily Scrum meeting accumulated. Upon reflecting on the causes of such inefficiency, the teams reached the conclusion that the very dynamic of the meeting itself could be causing the problem.

What plan of action was proposed?

We had read Jeff Sutherland's paper at http://jeffsutherland.com/ScrumMetricsHICSS2013BWSubmissionFinal.pdf and liked his proposal to change the approach of the daily Scrum meeting. Instead of carrying out the meeting as a function of each team member, Jeff proposed carrying it out as a function of each story of the sprint backlog. As the coach, I mentioned that the paper existed and that perhaps the team would be interested to learn about it. In fact, the team was pleased with the idea and accordingly implemented a plan of action to test the change in the next sprint.

How was this change in approach executed?

In the following sprint, the team started in the same place as always, but this time it began to respond to the classic questions based on each story of the sprint backlog. This meant that one or several team members (depending on how many were involved in the story) relayed all that they had done around that particular story, what they were going to do, if there had been blockers, and what things were needed to close it. They did not move on until all relevant issues around the story at hand were exhausted. This process continued until the last story in the sprint backlog was discussed. It should be noted that the recommendation is to start talking about the most important story and continue in descending order of importance.

What advantages have there been since changing the daily Scrum meeting?

Given that the product owner participates in every daily Scrum meeting, this approach allows him or her to hear from the team about how the development of the product is going -- i.e., this approach is oriented around the product, not around who did what. The important thing is that the product is being developed, and in Scrum the team, in its entirety, executes development. Conceptually, we define teamwork as a group of people with a common goal (vision) working in a highly collaborative environment.

As a result of the shift, an improvement in the efficiency of the team was noted almost immediately. It is assumed that this was due to the fact that everyone who was involved in a given story spoke when that story was being discussed, thereby improving the focus. This is in contrast to the traditional dynamic of the daily Scrum where, oftentimes, there would be disruptions. For example, if two developers were working on the same story, the group had to wait until both spoke in different turns in order to sufficiently understand past or future actions in regard to the story.

What's more, this shift of focus to the story required the entire team to reinforce its knowledge of the product being built, as all their activities were now concentrated on the product and not on the tasks of the developer.

The fact that there is no floor for each developer to speak allows other team members, who might be blocked in their story, or might have simply finished, to try to collaborate in closing the story being discussed instead of starting a new one.

What disadvantages have been observed upon implementing the change?

As is known, any such process change is analyzed in the following retrospective meeting in order to identify advantages and/or disadvantages. In this case, the main observed disadvantage was that it was difficult to detect when a team member was left without work. In the daily Scrum meetings, now, the discussion revolves around the stories and not around what the individual is doing. Thus, the team members have to be more proactive in addressing this "idle" state going forward.

In the same vein, one can appreciate that it might not be so obvious when a teammate is overwhelmed with tasks.

As coach, my viewpoint is that this disadvantage can be turned into an opportunity, given that it forces the team to demand more and to better self-organize. Everyone is responsible for employing his or her time efficiently. Everyone is responsible for seeing where the development process is stuck, in what story. And everyone is responsible for determining how to work together in order to find a path forward. In fact, a team that took part in this experience found a way to mitigate such disadvantages. For example, this team modified the dashboard so that, visually, it was easier to see where each team member was in the process.

Is there data with respect to implementing this change?

We have gathered some numbers and indicators through a survey about this practice, in line with the following participants:

  • Company A*: Team A1 with 3 team members, Team A2 with 4 team members, a ScrumMaster for both teams
  • Company B*: Team B1 with 7 team members and a ScrumMaster
  • Company C*: Team C1 with 4 team members and a ScrumMaster
(* Some of the companies involved preferred to remain anonymous, so I have decided to not include actual names.)

According to the above data, we can analyze the numbers in terms of how many people were directly involved. In total, there were 26: 4 product owners, 18 team members, and 3 ScrumMasters. We looked for feedback and asked everyone the question: Given the shift in approach of the daily Scrum meeting, which one of the following Scrum values grew the most: Focus, Courage, or Commitment? The results of the survey are illustrated in the following graph:

ledesma-chart.jpg
 

My reflection

To close, beyond the numbers I leave for your analysis, I would like to highlight that I observed firsthand the teams working in a way that crystallized the concept of "team" as conceived by Scrum. That is, where everyone is truly motivated and works in a sustainable fashion. Where everyone cultivates the credo "the sum is larger than its parts." And where the goal is to deliver incremental products of the highest quality to the client in the best possible time-to-market. The groups brought this concept of team to life.

Try to change something, observe how it functions, learn from it, change it again! And if something has to fail, it is best if it fails sooner rather than later!

Article Rating

Current rating: 4.3 (7 ratings)

Comments

David Lowe, CSP,CSM, 11/14/2013 2:14:17 AM
I'm totally with you on this: we started doing the same about 6 months ago and immediately noticed similar improvements in flow of work, improved focus, increased morale. After 6 months we still prefer this way and never have a problem with 'idle' team members (because they say "hey, I've finished x, so should I pick the next thing up or does anyone want some help"). Also, because people have to explain progress on a story rather than what they did yesterday, you still get to see if someone is struggling.

Thanks for bringing this to the SA forum. Oh, and don't forget to come back and tell us all how it's going in 6 months :)
Phillip Stiby, CSM, 11/14/2013 4:31:13 AM
Interesting, this is something I will consider bringing up in a retrospective as something to consider. Quick question what are people thoughts on the July 2013 scrum guide changes on the daily scrum?
Joseph Albanese, BBA, MBA, CSM, CSM, 11/15/2013 7:38:55 AM
This sounds like a good idea. I would suggest a hybrid approach whereby the traditional method is used in the beginning of the Sprint and toward the end, just as the focus shifts from burndown to completed users stories, the scrum focus shifts from individuals to user stories. My teams already make this shift and it works well.
Sebastián Maciel, CSD, 11/16/2013 7:25:00 AM
Great article Gabriel! I will consider that a an option for the next Retro
Jorge Emir Ramírez, CSM,CSD,CSPO, 11/18/2013 10:26:13 AM
Great job Gabriel!! Very interesting.
Reema Chetri, CSM, 11/22/2013 1:27:11 AM
Very interesting. I would definetly want to give it a try for my upcoming sprints. Thanks Gabriel for sharing this...
Would also be interested to know if it has any impact on the time spent on Stand-up meets.
Veronica Stewart, CSP,CSM, 11/22/2013 10:48:41 AM
Great article Gabriel- I have tried out user stories are the primary focus in the past when it has become apparent people were focused on providing an update versus discussing what needs to get done in order to completed the story. I also observed how it self facilitated the questions or concerns on stories not yet started or if there were any dependencies missed during grooming and planning.
Brian Camphausen, CSM, 12/19/2013 2:42:34 PM
Our team has implemented this in the current sprint to try and get away from an update focus to a getting stories done focus. I am hoping for the same results seen above.
Tom Rutherford, CSM, 12/19/2013 4:38:04 PM
Thanks Gabriel, I work with a distributed team and have been struggling to come up with ideas to increase team collaboration across the different locations. Will give this a try next sprint!
Bill Ambrosini, CSP,CSM, 12/19/2013 5:35:21 PM
Thanks Gabriel. I read the same article from Jeff Sutherland and tried this same thing after reading it. The team had a hard time adjusting at first. After our first sprint doing stand ups this way the team adjusted and they are now focused less on what they alone did and more on how each story is progressing. We talk about the stories from top to bottom in priority order. So if we don't have anyone working on a story it's ok as long as it's lower on the sprint backlog than other things that are actively being worked on. It's interesting to see what happens when we get to a high priority story in the sprint backlog and nobody is working on it. The silence tells the story and the team knows that they have to shift their focus without me telling them.

It's been a great shift for us.
Nick Henson, CSP,CSM, 12/20/2013 10:59:54 AM
This is something we have tried with one of our kanban component teams (supporting agile and waterfall project teams).

It does increase flow and reduces cycle time.

We are now looking to try it with our scrum ptoject teams.
Nandish Balareddi, CSM, 12/22/2013 12:54:24 AM
It is interesting article, thanks for the post.
The Article says, "They did not move on until all relevant issues around the story at hand were exhausted. This process continued until the last story in the sprint backlog was discussed". We have done this and we could hardly complete 20% of stories in 15 minutes of daily scrum. One time we decided to continue and it went on for 2 hours and team members held in the meeting for not so relevant discussions to their areas.
Another dis-advantage in daily scrum changes is a large part of team start focusing on a blocked story and all the other stories get piled up or any other important impediment may be over looked until last minute. The advantages listed above are definitely there. SM should schedule meetings with smaller groups for blocking or complex stories, in my opinion.
Robert Carstons, CSP,CSM, 12/26/2013 1:28:09 PM
Good article, Gabriel! I also read Jeff's paper, and really see some opportunities to measure and improve performance of my teams. I'm going to try the suggested approach to the daily standup letting the sprint backlog be the driver. I'll let you know how it goes. Thanks!
Gabriel Fabian Ledesma Montaldo, CSP,CSM,CSPO, 1/16/2014 12:12:27 PM
Thank you for all comments and feedback. Thank you again, I appreciate so much. Scrum and Agile are my passion. Because it´s the best way to working with high quality of life. Cheers!
Gabriel Fabian Ledesma Montaldo, CSP,CSM,CSPO, 1/16/2014 4:03:28 PM
Thank you for all comments and feedback. Thank you again, I appreciate so much. Scrum and Agile are my passion. Because it´s the best way to working with high quality of life. Cheers!
Usha Ramaswamy, CSM, 1/16/2014 11:12:03 PM
Interesting! I will share this with my teams and seek their comments.

I do think that implementing this within the time box needs a lot of discipline. The Scrum Master has to keep doing a time check.
Ajit Singh, CSM, 1/17/2014 2:44:48 PM
Gabriel, will this result in increase the duration of daily meeting?
Ajit Singh, CSM, 1/20/2014 9:37:25 AM
Gabriel, will this result in increase the duration of daily meeting?
Mike Fahmie, CSM, 2/17/2014 3:53:51 PM
We just started this approach after it was first adopted by an internal team on another project at our company, and we noticed the difference right away. For years our VP ran the daily individual updates, so it was really difficult to sell them on the mentality that the daily scrum is a report to your team members not your SM.

This approach has quickly helped self organization kick into gear. We are realizing sooner when we begin to fall behind on a story and are mobilizing to make sure we got back on track.

I do agree that the biggest challenge is identifying when someone either does or doesn't have a lot of work, but like Gabriel, I'm using this is an opportunity for team members to show their self-initiative. When it's less obvious that they've only committed to an hour's worth of work, it's easier to hide in the corner. However, before long the team members began noticing and calling each other out on it. I was skeptical if this would work or not, but a couple of sprints in I see what we were missing. Great read Gabriel!

@Ajit Singh - At first it did seem to make the meeting a little longer, but once we got in the habit of it, we were back on track just a couple of days into the sprint.
Gilbert Villanueva, CSM,CSPO, 2/24/2014 2:55:01 PM
Wow, I guess I have been doing it right all along - well sorta'. While we don't go down all the stories, I have always keept the "What I did" and "What I am going to do" centered on the user story tasks. Since we only work on User story tasks, the conversation IS by default centered on the user stories. Or am i missing something?

You must Login or Signup to comment.