The Power of Pairing

You may be thinking, “Great, this is one of those hipster blog posts where they try to convince you that paired programming is THE solution to all of your problems.” Rest assured, I don’t believe Extreme Programming is the best solution for every problem, but I do believe that it can be a good foundation for successful software delivery. I wanted to blog about some of my experiences I have had and hopefully share some insightful knowledge with anyone who has an interest in Paired Programming. In order to illustrate my experience I am going to create a generalized story of a typical project and show a couple of challenges that can easily be solved with paired programming.

Example Story - ABC Corporation

ABC Corporation hires a group of consultants to decompose a monolithic application. Specifically, ABC hires four developers to fit into their existing product team. They have four existing developers, a UX/UI designer, and a product owner. ABC Corporation makes….. warm winter coats (at the time of writing it is particularly cold here in the Midwest this December). ABC Corporation is expanding rapidly as business is booming! ABC currently has a monolithic application they use to run their business and realize it won’t fit their upcoming needs. ABC’s stakeholder team also wants their resources to learn new cloud native development patterns and best practices.

ABC’s team is located in Iowa and the consultants are located in California. ABC’s resources are helping to develop software while being the main contact point for domain knowledge items that the consultants will need to understand. I will now walk you through some challenges that the consultants ran into during the project.

Challenge #1 - Lack of Domain Knowledge

The consultants coming onto the project lacked a fundamental understanding of the domain that the developers at ABC Corporation had acquired over the many years they had been working there. Often, the consultants had to call the developers at ABC and have them explain the domain language. This resulted in context switching for the developers at ABC and some very slow initial couple of sprints as the team ramped up.

Challenge #2 - Teamwork and Coordination

One of the challenges both teams faced was implementing new patterns and practices introduced by the consultants. The developers from ABC had to take a lot more time to research the new cloud platform they were integrating, coding practices, and CI/CD setup and usage. The consultants ended up having to spend a lot of their time in code reviews and pull requests. ABC’s stakeholders became a little frustrated with the consultants as they felt their resources could not make any progress compared to the consultants and were having trouble learning the new concepts.

Challenge #3 - Knowledge Transfer and Handoff

The consultants had to hold multiple sessions explaining the work they did. They tried to keep some documentation up to date in a team collaboration software suite ABC owned but it got stale and out of date as they kept working. When they transitioned off of the project, there were some serious gaps left in the minds of the resources at ABC.

Knowing the problems the team faced at ABC, I’ll frame up a new teaming model that would have allowed them to avoid these problems in the first place. Instead of having 2 teams split up across the country, ABC decides to create one large product team co located in Iowa for the duration of the engagement. They fly in consultants each week to Des Moines from California.

Solution to Challenge #1 - Pear Rotation and Co location

Working on the same product every day is significantly easier with the co located development team. Not only were they able to bounce ideas off each other and coordinate story development, they had knowledge transfer happening every time they rotated pairs. One of ABC’s resources was also a senior resource and had excellent domain knowledge and many contacts in the organization. The consultants were also able to get a better understanding of the user perspective and develop empathy for the poor Midwesterners needing those cold winter coats. Whenever the consultants had questions on the domain it was easy for them to ask questions and get in touch with other subject matter experts across the organization.

Solution to Challenge #2 - Shared Ownership

The entire team developed shared ownership of the codebase and developed strong bonds and levels of trust. They all agreed on a set time frames during the day to work on stories related to the project and get lunch together. They got to know each other, and even though some of the first pairing sessions were a little rough, they became highly efficient as pairs as they understood each other’s communication styles. Whenever the product owner identified a bug or functionality that needed to be changed, they did not blame each other, and instead whichever pair was free just jumped in and resolved the change.

Solution to Challenge #3 - What KT?

When the consultants paired with ABC’s resources every day, there was no heavy documentation or handoff needed of the work they had been doing. The team had been pairing on everything including CI/CD setup, application architecture discussions, and the daily story work. Since the team was co-located, the product owner also had a real clear picture on what the team had accomplished and the challenges they faced during delivery. The only thing the consultants had to do was wish the resources at ABC their best, even though it was a little sad to leave, knowing that they were fully prepared to keep working the next day.

Final Thoughts

I hope you can see how paired programming fits well into the picture here. The story I attempted to describe is common across many large corporations going through a digital transformation process from their legacy applications to the cloud. The empathy involved during paired programming cannot be empathized enough. When you pair with someone every day you get to really understand what motivates them and you can grow from their experiences and knowledge. You also get a better vision and empathy for the end user of the product you are building! Don’t get me wrong, paired programming is not all sunshine and roses, it is very difficult and draining mentally. It requires lots of effort from each team member and not everyone has the personality type to sit with someone 5 days a week. I have sat with a fellow pair at the end of the day over dinner and apologized for some shortness I displayed with them during a pairing session we had that day. Even though there are challenges, I believe the benefits are truly incredible. I find paired programming can result in the most effective and rewarding work you will ever accomplish.