This article tells the story of our experience implementing a shift in approach during the Daily Scrum meeting. We went from a typical approach centered on each individual to one centered on each story of the Sprint Backlog. The idea for such a shift was inspired by a Jeff Shuterland 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 such a shift in approach. But, before launching into explanation, it is important to provide you with the context of this experience.
Context
I have been an Agile coach for more than nine 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 the Daily Scrum meeting, 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:
- What did I do yesterday?
- What blockers did I have?
- 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 finished. 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 itself of the meeting could be causing the problem.
What plan of action was proposed?
We had read the paper Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft by Jeff and liked his proposal to change the approach of the Daily Scrum meeting. Instead of carrying out the meeting in function of each team member, Jeff proposed carrying it out in function of each story of the Sprint Backlog. As coach I mentioned that the paper existed and that perhaps the Team would be interested to explore its suggestions. 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 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 proceed 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 each Daily Scrum meeting, this approach allows him or her to hear from the Team with respect to 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 team efficiency 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 regards to the story.
What’s more, this shift in focus centered on the story requires the entire team to reinforce their knowledge of the product being built, as all their activities are now concentrated on the product and not on the tasks of the developer.
The fact that the meeting does not revolve around the developer but rather the story allows other team members, who might be blocked in their story or 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 was is difficult to detect when a team member was left without work. In the Daily Scrum meetings, now, the discussion hinges on the stories and not around what the individual is doing. Thus, the team members will 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 their time efficiently, and everyone is responsible for seeing where the development process is stuck, in what story, and 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, they 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 scrum master for both teams
- Company B: Team B1 with 7 team members and a scrum master
- Company C: Team C1 with 4 team members and a scrum master
(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, 19 team members and 3 scrum masters. 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, Commitment?
The results of the survey are illustrated in the proceeding graphs:
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” 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 than later!