Pair programming is a perfect tool for building a quality culture. Quality starts from a single well written line of code. Having somebody who constantly challenge the way the program is written, who can spot a defect at a glance, significantly reduces the number of issues in your product. This article is not about pair programming rules. You can find many interesting materials by looking for XP (Extreme Programming) practices, but less is more — this article contains enough information to start.

Social skill to learn

Pair programming is a social skill that takes time to learn. In this article I will focus on the human factor and fears related with pair programming. This is an underestimated element that often leads to the abandonment of pair programming on first attempts. This text tries to show which needs and fears should be considered when building this social skill. At the end there are few hints, how to create an environment where those fears are under control and will not sabotage pair programming at an early stage of building this practice.

Scarf Model

In 2009 David Rock wrote a brilliant book “Your Brain at Work”. We all are “products” of a long evolution. Our brains have still parts which operate the same way like thousands of years ago, when we had to hide in the caves and fight with wild animals. Those parts in our brain react automatically and helped us to survive. They are still working in every developer brain and are responsible for “away” or “toward” instant reactions. When we feel that our status, certainty, autonomy, relatedness or fairness are threatened we run away or attack (“away” response). Whenever we feel safe in those areas we are more willing to explore new things and are much more open for pair programming (“toward” response). David Rock presented a model which could help us to understand how our brains work.

Looking from SCARF model perspective, pair programming touches mostly two needs: status and autonomy, but all of them could trigger “away” response.

Pair programming put developer at risk of compromising his or her status in many ways, from looking ridiculous sitting in front of one computer to revealing weaknesses in logical thinking or problem solving skills. When we create code shoulder to shoulder, we uncover our thinking process and our mistakes are exposed. Autonomy thread is quite obvious — your pair programming partner will impede your preferred way of coding and change my daily routines. Moreover, there is a chance that one will get into the conflict if I fundamentally disagree with someone’s solution (relatedness need). Fairness could be an issue when there is a strong culture of personal achievements in your organization. As you can see, all SCARF model needs could be affected by pair programming.

Knowing that, it’s still possible to rewire the brain. Learning new habits happens when people can safely try new ways of doing while experiencing the benefits of those new methods.

Simulation makes our brain to rewire more quickly

Learning pair programming could be speed up, by a short feedback loop of results and safe, relaxed state of mind.

Developers can experiment with pair programming, but usually impact on the product could be noticed after some time. Our brains cannot close the learning loop and could drop new habits. Instant feedback loop is crucial. When the time from experimenting with pair programming to better product quality is short, we significantly increase the chance of adopting this practice.

ScrumTale as a pair programming workshop

In April 2019 together with my friend, who is a Scrum Master in a huge IT corporation, we had a conversation about pair programming. We already know that this will require learning new social skills. We came to the idea of using ScrumTale as a pair programming workshop to show benefits instantly and use the simulation to put team members into a state of flow emerged from fun and engagement.

ScrumTale is a Scrum simulation workshop, but it’s adaptable to other goals. In ScrumTale teams write a crime story in Google Docs (together, as a team). The biggest benefit of having a crime story as a product is the ability to instantly assess the quality of the product. It’s natural for humans to spot errors in text and have an impression about the crime story quality. It’s just obvious during the demo session.

ScrumTale is more like teaching platform which you can easily adapt and change, so we have spent some time figuring out a game extension for “pair programming” goal. We have modified the game by those rules:

1. In first sprint developers are not allowed to write in pairs.
2. In the second sprint developers must work in pairs using one computer.
3. In the third sprint developers must switch pairs from the second sprint.
4. In the third sprint developers must change the writer role at least once during the sprint.

He was amazed by the results. During demo sessions his team saw significant improvement in quality between first and second sprint. Apart from that, they spent some time discussing social difficulties and brought interesting ideas of how to overcome their fears. This team is now a role model in pair programming practice.

Summary

1. Pair programming is a great tool to improve product quality.
2. It’s a new social skill to learn for developers.
3. Human fears are underestimated pair programming success factor.
4. To learn new habits fast, our brains need to be in a relaxed, flow state.
5. Close feedback loop of results significantly increases the chance to adopt new habits.

Pair Programming photo source: https://www.flickr.com/photos/damienpollet/5048830734