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.
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
, or Commitment
? The results of the survey are illustrated in the following graph:
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!