Waiting on a Miracle
A Scrum master recently asked Todd the following question:
I’ve noticed that my development team members are taking forever to get a code review from the architecture team. It’s wreaking havoc on our sprints because we can’t consider anything done without having that code review. Any advice on what I can do?
This scenario is an example of how outside dependencies can block a development team. Clearly, the architecture team’s code review was an impediment that needed to be addressed. To create transparency around the bottleneck that these code reviews were creating, Todd suggested the Scrum master work with the dev team to map out their workflow. She took his advice and, a week later, the dev team had identified each stage that a PBI had to go through during a sprint to get it to a “done” state. The development team then visually represented their workflow on their Scrum board and did a great job keeping it up to date.
As the weeks passed, this visualization gave the Scrum team members insights into the development team’s work that they’d never had before. It allowed the Scrum master to see a pattern of PBIs getting stuck in the “Ready for code review” and “In code review” columns. The Scrum master suggested to the dev team that they start writing the date that a PBI arrived in the “Ready for code review”, “In code review”, and “Ready for testing” columns so they could quantify just how long it was taking for the architecture team to complete code reviews.
By collecting this data, the team discovered that it was taking and average of five days for a PBI to move from “Ready for code review” to “Ready for testing.” Five days seemed like an eternity considering they were using two-week sprints. The development team hadn’t considered changing their code-review process or even treating it as an impediment because it had been in place before the organization adopted Scrum—it’s what they’d always done. But bringing transparency to the 5-day bottleneck made it clear that the code-review process needed to change.
The Scrum master now had the info that she needed to discuss the code-review process with the rest of the organization. Speaking candidly with the architecture team, she shared the five-day average time that their code reviews took. They acknowledged that this was a problem but didn’t know how to solve it, so the Scrum master and the head of the architecture team escalated the issue to folks in upper management. Faced with the data about the duration of the delays, and wanting to speed up the development team’s progress, the managers agreed to a big change: They allowed the development team to start doing their own code reviews. After an initial adjustment period, the dev team can now perform the complete workflow for their PBIs—including code review—in far less time than it took when they relied on the architecture team. Everyone in the organization is pleased by the team’s increased productivity, and the architecture team is happy to have one less task on their plate.
What we really like about this solution is that it also re-enforced the need for truly cross-functional teams. As we discussed in Chapter 6, The Development Team, the development team should have all the capabilities they need to complete their work. In this scenario, that meant the developers needed to level up their ability to review and improve code.
Identifying their workflow could be just what your development team needs to take their sprint backlog to the next level. There are typically a lot of stages that a PBI has to go through before it can be considered “done,” and identifying these stages can help unearth dependencies, bottlenecks, and impediments—including ones the team hadn’t noticed before.
To understand your team’s workflow, have the development team members work together to define all the stages that a PBI in the sprint backlog must go through to get to done. You can use the example chart we included in this section as a starting point, but remember that every dev team has a different workflow because of the specific product they’re building, organization they’re in, and their own definition of “done.”
Once the development team has outlined their workflow, they can measure the cycle time it takes to complete a PBI in the sprint backlog: the amount of time a PBI takes from start to finish. When measuring cycle time, it’s important to know when a PBI is active and when it is finished. At the conclusion of sprint planning, when the sprint backlog has been created, none of the PBIs are active yet. PBIs becomes active when the development team begins work on them. In our example workflow chart, a PBI becomes active when it moves from the “To-do” column to the “In dev” column, and it finishes when it moves to the “Done” column. If it’s helpful, you can also measure the cycle time between each stage of the workflow.
Using cycle time as a metric can give the development team additional transparency into the sprint backlog. A team can then work to reduce their cycle time and look for stages in their workflow that are bottlenecks, such as the architecture code reviews we discussed earlier.
Once you’ve gathered some cycle-time data, you can talk to the dev team about the cycle time of their workflow as a whole and/or between each phase of the workflow. Inspect phases that have longer cycle times than others and try to figure out why. You might discover that the dev team lacks certain tools they need, has organizational constraints or outside dependencies, or even lacks a necessary skill set. Once you identify impediments, work with the dev team and the wider organization to remove them.
Understanding and measuring cycle times is the tip of the iceberg when it comes to new ways the development team can manage the sprint backlog and make it more transparent. Another technique we’ve come to love is implementing the Kanban method. Keep reading to learn how you can start using Scrum and Kanban together.