The software development team was on day eight of a ten-day sprint, and they had completed over 90 percent of the committed tasks on the sprint board. The team was excited to have two days left of the sprint, with nearly all their work completed. There was a mood of victory in the air. However, the product owner and I had knots in our stomachs because we knew things were not as great as the team believed. The reason? The team, so far, was not able to demo any of the stories to the product owner for acceptance. As the ScrumMaster, I had mentioned this risk to the team a few times during the sprint, but it fell on deaf ears. The team saw the task burn-down chart and was convinced it was on track.
On day nine, the team was 95 percent task complete with still no demos for the product owner, and I broke out the Tums®
. At the end of day ten, the team finally demoed some completed stories, which were accepted by the product owner. However, she was not happy. They were the lowest-priority stories on the sprint backlog. The team barely delivered any business value to her, the company, and most important, to our customers. Later that day, the product owner and I had to provide an update to the business. Before going into a status meeting, I gave her the rest of my Tums, because this was going to be a long and uncomfortable meeting for the both of us.
Unfortunately, what happened to my team is all too common for Agile teams. They see the task burn-down in isolation of the big picture, a tendency that provides a false sense of security. Following that experience, I went into inspect-and-adapt mode and began to investigate other tools and coaching techniques to augment the task burn-down chart and help the team with situational awareness. I came up with an assortment of complementary tools and coaching techniques that I leveraged from Lean, Kanban, and Scrum that really made a difference in my particular situation.
First, I replaced the task burn-down with a task burn-up that allowed the team, and the product owner, to see if any added, committed work was affecting the team’s ability to deliver its sprint commitments. My team strove to minimize any work added to an inflight sprint, but this could not always be prevented.
Second, I introduced a story point burn-up so that the team could see whether the number of stories being accepted was commensurate with the number of tasks being closed. For example, if the team had completed 60 percent of tasks with no stories done and accepted, then the team was probably working on too many stories in parallel and not focusing on the stories with the highest business value. This would force the team to see that their zeal to work on as much as possible was actually slowing them down instead of helping them speed up.
Third, I introduced the concept of flow, which is a Lean concept. The term flow
refers to how work moves through a system and how it can be optimized. If I could demonstrate to the team approximately where and when the bottlenecks were occurring, they could discuss and make informed decisions instead of guessing where the problems might exist. To do this, I employed the use of a Cumulative Flow Diagram. It showed when, during the sprint, the team’s productivity stalled out and where the team sped up. It was a real eye-opener for the team. During subsequent sprint retrospectives, I would compare the previous sprint with the one we had just finished so that the team could see whether the solutions we implemented helped or hindered our flow. The team was able to identify positive or negative trends.
Fourth, I introduced a Cycle Time chart. This is another Lean concept that measures how long it takes for a task or story to complete once it starts. I also used this metric during retrospectives to show the team whether the cycle time stayed the same, increased, or decreased. It showed trends so that we could look at our process to identify where it was getting stuck. For example, we noticed that environment availability delays were hurting our cycle time, so we bubbled this impediment to the Scrum of Scrums, where it was given the proper attention and resolution.
In addition to the tools I leveraged, I also made sure that I was more direct with my team regarding my observations, especially about risks to our sprint commitments. I didn’t want the team to have any misunderstandings. I made sure that the product owner was in the room as well, so that everyone had a common understanding of sprint and release health. Also, I strongly advocated the use of swarming on stories with high business value that were getting stuck. My team was sometimes so focused on completing tasks that they lost sight of what the real focus should have been: delivering business value.
I implemented all of these new concepts and tools methodically and incrementally so as not to overwhelm my team. Each time, I wanted to make sure that they understood why I was introducing a new concept or tool and its associated benefits. I wouldn’t introduce another until I was confident the team was ready to absorb and apply it. Over the period of a release, with five development sprints (two weeks in duration), my team became successful in completing their committed work in the last few sprints. This success carried over into the next release, even as we experienced changes in team-member composition.
I know that this success story will not be able to be replicated in all teams under all circumstances, but I believe it does provide a recipe for success that other ScrumMasters can follow if they so choose:
- Spend time to truly observe your team to understand how they are performing, individually and as a unit.
- Develop different metrics to measure how your team is executing on its commitments instead of using guesswork.
- Develop a performance goal you want your team to achieve, and develop a strategy to incrementally achieve that goal.
- Discuss the strategy with your team, providing them with the reason for the approach and what’s in it for them.
- Apply kaizen to your strategy to capitalize on the Agile inspect-and-adapt method with the goal of continuous improvement.
I believe that, as ScrumMasters, we owe it to our teams, and ultimately to our customers, to constantly learn and apply new strategies, tools, and frameworks with the goal of product excellence. This will help empower our teams to respond to rapidly evolving market needs. And let’s face it, there will always be market, technological, and organizational challenges waiting for us, and we need to be ready to respond. If not, we will render our teams ineffective, which is the antithesis of what we do as ScrumMasters!