Several years ago, I was the Scrum Master for a team working on a technology product. Two of the team’s Developers told me they would like to try pair programming.
At the time, I had no idea what pair programming was. The Developers explained that pair programming is a software development technique where two programmers work together at one workstation. One programmer writes code while the other reviews each line as the first programmer creates it. The two programmers switch roles frequently.
It seemed like an awful waste of time to me, but I suggested that the Developers bring it up at the Sprint Retrospective to see what the other Developers on the team thought. Because no one—not even the Scrum Master—tells the Developers how to accomplish the work of the Sprint, it was up to the Developers to determine if pair programming was something they wanted to try.
The team decided to try it during the next Sprint, citing several reasons:
Increased productivity: Pair programming can result in increased productivity because two people working on a problem together can problem solve more quickly.
Improved code quality: Having two people review code while writing it can catch mistakes early, leading to fewer bugs and a higher-quality final product.
Enhanced learning: Pair programming can be an excellent way for junior developers to learn from more experienced colleagues and vice versa.
Promotes teamwork: The collaboration of pair programming can lead to a more positive work environment.
At the Sprint Planning meeting, the team selected one of the Sprint’s most challenging Product Backlog items (PBIs): to reduce the runtime of a specific batch job. The batch job in question was critical and also very complex. It tended to fail unexpectedly, and its runtime sometimes exceeded the amount of time allowed for that particular job, causing a cascading series of failures.
The team decided to deliver this PBI using pair programming.
At the time, the Scrum Team worked in a shared space, which included desktop stations arranged beside each other on long tables. During the Sprint, I would see the paired Developers sitting side by side. One developer would type, and the other would periodically point to the screen, commenting or discussing ideas with their partner. They were visibly engaged and excited by their work, and I thought that maybe there was something to this pair programming thing after all.
During the Daily Scrum, the paired Developers excitedly talked about the improvements they were making. At the Sprint Review, they revealed their astonishing results. Not only had they reduced the run time of the batch job, but they reduced a job that ran in eight hours to just 15 minutes! They also created a much more robust solution that no longer failed every other night. The Product Owner and stakeholders were thrilled.
At the Sprint Retrospective, the Scrum Team met to discuss what went well during the Sprint and identify improvements to their approach to the work. Both Developers involved in the pair programming experiment were ecstatic about what they accomplished using the technique. They unequivocally agreed that they could not have achieved their results by working independently. Pair programming helped them unlock the creativity that comes from collaborating to achieve spectacular outcomes.
Based on the Sprint Retrospective, the Developers decided to expand their use of pair programming. While individual Developers would continue to deliver smaller, less involved PBIs, they would turn to pair programming when the work item was more complex or needed a creative approach.
Over time, the Developers used pair programming more frequently, and we realized an unexpected benefit. It began to improve the team’s flow of work during the Sprint.
The team found that pair programming limited the team’s work in progress (known as WIP in Kanban) by providing a built-in mechanism for reviewing and testing code while it was being written. The practice reduced the number of defects in the code, leading to fewer tasks in progress because the Developers didn’t have to fix them later. The pairs were able to complete work more quickly and efficiently.
By limiting WIP and having a laser focus on completing fewer PBIs simultaneously, the team began delivering more and improved the quality of their work, thus increasing their ability to deliver a Done increment, meeting the Sprint goal by the end of every Sprint.
Conclusion
Pair programming can be a valuable tool for software development teams looking to increase productivity, improve code quality, enhance learning, promote collaboration and reduce WIP to improve workflow during the Sprint.
To learn more about Kanban practices, such as limiting WIP, signup for Rebel Scrum’s live virtual Professional Scrum with Kanban course. If you are a Scrum Master looking to take your team to the next level, register for Rebel Scrum’s upcoming Professional Scrum Master course. For advanced Scrum Masters, signup for Rebel Scrum’s Professional Scrum Master II course.
Join us for an exciting day of learning about how to apply Scrum in your unique situation at this year’s Scrum Day USA, scheduled for September 14, 2023, in Madison, Wisconsin, USA, brought to you by Rebel Scrum.