Making Big Improvements with Small Changes
Written By: Mitch Rogers
As we looked ahead to a daunting year of large initiatives and looming delivery dates, our engineering product team was trying to discover its identity. The team had a total changeover in personnel bringing on new engineers and leaders. This has forced the newly appointed Tech Lead to come up to speed quickly in a complex domain. Over the past several months, the team has made many small incremental changes that has made a large impact to the team.
Retrospectives have been critical for the team to analyze the past and bring new ideas to move forward. The team utilized several tools and measurements to identify opportunities that could be addressed.
The team had identified that by working on large stories, they were having challenges getting them fully completed before the end of the sprint. This caused the end of the sprint to be stressful and a bit chaotic to get the stories finished. Often, sprint planning for the next sprint would have to be delayed getting just a little more time to complete the work within the current sprint.
The team recognized that breaking stories down to smaller bites of functionality would allow them to finish stories throughout the sprint. The impact was noticeable. The stories were developed quicker and delivered throughout the sprint rather than at the end. They could even pivot within the sprint if a story was blocked. This has produced a throughput and velocity increase of 8.6%.
Several metrics indicated that the large stories were causing longer code reviews, delayed commits to the repository, fewer coding days, and high merge times. With the smaller stories, they were able to complete pull requests faster because the amount of code to review was drastically smaller. The reviewer didn’t have to review large complex changes. This has increased the coding days and commits per day by 50% and the change impact by 130%.
While these metrics help the team understand the data, their focus was not on improving the metrics. Rather, they were focused on sprint delivery and getting smaller bits of functionality done quickly. They wanted to be able to get into the story, make the changes, deploy, and move on to the next one. These measurements were used to visualize the impact of the decisions the team made.
Another small change was the introduction of a new role for the team called the Sprint Lead. This is a rotating role each sprint where one of the engineers is identified as the Sprint Lead. This person is the one watching the board and helping all the engineers work through their stories. They are the first to complete pull requests, testing on the story and helping with completing the deployment by verifying the change. This has reduced the burden on the Tech Lead and provides clarity on who is doing the code reviews and testing rather than just leaving it up to anyone on the team.
The Sprint Lead role also provides leadership opportunities for each member of the team. Several of the engineers have expressed that being the Sprint Lead has helped them gain a broader understanding of the domain and have found the experience to be very beneficial.
While these small changes have had a large impact on the team, they continue to find ways to optimize and improve. The retrospective meeting has been the catalyst for the team to review the data, discuss how they are doing and make adjustments.
