Pair-Programming: A Scrum Master’s Perspective

In the blog post Pair Programming: A Developer’s Perspective, Mingwei helpfully teased out the benefits and pitfalls of the practice of Pair Programming.

Typically, pair programming is viewed as the Development Team’s concern -the kind of stuff only techies would and should care about. So, if you happen to be the Scrum Master and your team members are advocating this, you’ll have your work cut out for you. But still work that is worth your time, nonetheless.

So here are a Scrum Master’s perspectives on pair programming.

Who Are You and How Are You Involved ?

You are the Scrum Master. The servant-leader who coaches the Development Team in self-organisation. You are adamant pair programming is good for delivery in the long run. But if the team is not considering this, you worry that enforcing this practice will interfere with their autonomy. After all, you have the Scrum rules carved into your heart. Remember that bit about “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into increments of potentially releasable functionality?” To push for pair programming is similar to telling them just that. You fear breaking the Scrum rules. Your conscience is killing you.

All is not lost, though. There is another point we can make about a Scrum Master’s service to the organisation, namely “causing change that increases the productivity of the Scrum Team”. If you are convinced pair programming increases productivity, it would be good to first identify what concrete productivity problems are happening, and connect that to how pair programming can help, while keeping in mind our principle is to be as lightweight as possible in our process. It is not about mindlessly implementing every promoted idea and selling them as “good practice.” “If there is no problem to be solved, then there is no point implementing a solution.” Pair Programming is a solution to problems. The one over-arching smell which pair programming might help (note the word “might” because problems could run deeper) is that of a silo’ed knowledge of the domain/system/code within the team. This smell manifests itself in symptoms like:

• bottleneck in team due to high inter-dependency between team members
• uneven spread of work within the team in an iteration/sprint
• fear of changing unfamiliar parts of the system
• drop in team’s engineering practices over time
• inability of some team members to estimate a piece of work
• lack of confidence in supporting a production system
• low bus factor in the team (also known as panic in the team when a critical team member goes on a really long vacation or worst — “you better be on call while holidaying in a beautiful remote island.” )

Circling back to the Scrum Master’s role, it is true that you can’t really enforce anything else apart from the Scrum rules. But there is nothing stopping you from influencing and encouraging the Development Team’s experimentation with pair programming in order to be more productive, especially when you are able to connect pair programming as a solution to productivity-impeding causes. Even if you fail, continue to listen to understand their concerns and objections. Give the Development Team time to digest and try again some time later.

It’s a huge weight off your chest if you find yourself in the enviable position of having team members who are keen on trying pair programming. After all, this is an initiative from the Development Team. But don’t assume this practice will be welcomed into the team’s way of working.

Uh Oh...There Are Concerns from the Sponsor and Product Owner

It is normal that there will be concerns or objections pertaining to the cost and impracticality of pair programming. Many would question why there is a need to pay two people to do the same job when one can do it “perfectly fine.” Of course, the key assumption here is the idea of “perfectly fine”. It is good to explore what this means. If it means delivering the project or product with the symptomatic smells as mentioned earlier, and accepting all the risks (technical, staffing, maintenance, knowledge) that it brings, then there really isn’t a reason for pair programming. This assumption is based on attempting to locally optimise the capability of each individual for the short term rather than the collective whole for the long term.

To be able to see pair programming in a positive light, a long term view is needed. This practice reduces staffing risk on the project or product. Although people might get sick or quit, this knowledge is already well shared within the Development Team. It increases the overall technical skill as experienced developers can do hands-on mentoring for junior developers. It also speeds up onboarding when there is a need to add more people to the team (with a caveat¹). In my experience, I have never encountered a case where the delivery speed dropped because a new person joined a team that does pair programming. In addition, the practice of pair programming helps to combat the unhealthy software development smells I mentioned earlier, which in turn, benefits the project or product development overall.

If you are interested in a researcher’s perspective on this topic, check out Laurie Williams and Alistair Cockburn’s The Costs and Benefits of Pair Programming.

Journey to the New World

Adopting the perspective of the Satir Change Model, the practice of pair programming is a foreign element that is injected to the team’s Old Status Quo.

You can almost predict that they will go through some stage of resistance and chaos. Strong, determined and well-gelled teams will probably be able to claw their way from chaos to the New Status Quo through relentlessly integrating the practice into the team’s life. In this case, there is less facilitation support you need to provide. However, the typical situation will involve a bit more help from the Scrum Master. Do not underestimate the adjustment needed for team members to transform to the New Status Quo, where pair programming becomes natural to the team’s practice.

From Chaos to the New Norm

Different people in the team have different Change Quotients² , or the ability to adapt to changes. Each person also brings their own expectations into how pair programming will be practiced in the team. These expectations are often assumed and creates friction whenever they differ. You can help the team to get on the same wavelength by facilitating their working agreement when it comes to pair programming. Focus on what values and behaviour they agree to bring into the pairing session. Consider having a discussion around how the embodiment of the 5 values of Scrum will help. Exploring Extreme Programming’s values of Communication and Feedback can be useful as well.

Look into :

• how disagreements should be resolved (this is inevitable when you have more than 1 brain thinking)
• permission to raise uncomfortable issues between a pair: Hygiene issues (e.g. sharing of keyboard/mouse, bad breath or body odour, pairing with a sick person) and sometimes, perceived attitude or attention problems

On the more practical side of things, have a starting agreement on the following areas (the team can always change it after trying it out):

• When to pair and when not to pair (a recommended minimum would be pair programming is a must on writing production code, while not mandatory for other activities such as experimenting or researching)
• How long to pair program before taking a break (pair programming will be more mentally taxing, and taking a short break will help to keep the pair productive). Try the Pomodoro Technique and see if it helps. Experiment with taking a break when the pair has finished integrating the code and has kicked off the automated build. The team can have other creative approaches.
• How often to swap pairs (a pair that sticks together for a long time may create a new silo knowledge, which is exactly what we are trying to avoid with pair programming). See if the team can adapt Promiscuous Pairing. Or perhaps a logical point to swap pairs (e.g. after a story is done), or even a time-based limit approach (every day, every half a day, every 2 hours, etc., but definitely not as long as every sprint). Try different ways to determine what is helpful. In the early days of Extreme Programming, there were even experiments that involved swapping pairs every 5 minutes. Extreme indeed.
• Core hours of pairing: Let’s face it — coding is not the only thing developers do. They need to reply to emails, spend time in backlog refinement, update time sheets, participate in daily scrums, and attend the occasional long-lunch appointments. In some cases, people also simply need some alone time ( This is pair programming, not Siamese-twin Programming). Setting a core hour of pairing helps each individual to better plan for the day. This also means that the core pairing hour cannot be exactly the same as working hours. It needs to be shorter so developers can do other things. If the idea of pair programming for most of the day is too high a bar, try experimenting with half-day pairing.
• Handling of interruptions and distractions: Unless you work in some sort of programmer’s paradise, you will never have the chance to do a full day of coding. Interruptions will happen. If core hours of pairing are established, developers can better plan meetings to happen outside of core hours to minimise interruptions. It is worth mentioning that the use of mobile devices can be particularly distracting to pairing (incoming calls and messages, social media updates, etc.). I have seen how the sudden popularity of smartphones in 2008 had impacted a good team’s Pair Programming practice. Unless there are urgent calls, the recommended agreement is not to have them around during pairing. After all, a healthy pair will take frequent breaks throughout the core pairing hours and they will have a chance to check their phones.
• Consider skipping the formal code review: If the team has an existing practice of code review in place or uses Git Flow’s Pull Requests, consider relaxing the requirement on codes that are pair programmed. pair programming produces a better form of code because code is reviewed on the fly. If one is unable to trust a pair’s work on the code base, you have a bigger issue that needs to be addressed.
• Sickness: If a person is sick, encourage the person to stay at home (if they must be in the office, then they should not pair up). Because knowledge is already shared through pairing, the team can operate well without the sick person around. Catching bugs would not be helpful (they have enough bugs to solve on their own, thank you very much!)

On navigating the implementation of pair programming between two persons of varying background (e.g. experience/novice pairing, introvert/extrovert pairing, etc.), I highly recommend reading Laurie William’s Pair Programming Illuminated .

Walk a Mile in Their Shoes

As a Scrum Master, you can join them in feeling that unfamiliar change. Offer to pair with a developer. You do not need to pair with them for a full day. Pair for 30 mins. Pair for an hour. Switch and pair with another person. Reflect on your experiences. In what ways did you feel uneasy? In what ways did your pair feel uneasy? What did you notice about the environment or the space where you were paired ?

“But I don’t know programming,” you say. Not a problem. Offer to be the Rubber Duck³ for a developer that is stuck.

Helping the Team to Perform

Pair programming can take some time to get used to. Like months. It requires a different mindset. The team will either adopt, reject or assimilate. Teams may fall back and return to the old status quo. Encourage teams to continue ironing out the issues. Run retrospectives to find out what issues they are facing, and what changes to make to improve their experience.

Consider comparing development metrics before and after pair programming (defects count, bus factor, estimation variation, time spent on stories, code cyclomatic complexity, automated test coverage, and velocity vs number of team member availability) to see the improvement. This serves as tangible evidence to encourage the team to move forward.

What does “performing” mean in pair programming? It means it is the default mode they will choose when working, even when under pressure. When that happens, the team has reached fluency in this practice. To borrow from the Agile Fluency Model’s view of fluency, it is “a habit of exhibiting the proficiency at all times, even when under pressure.” When you see that team members pair program by default (even under pressure), swap pairs often, naturally ask for pairing without hesitation when they are stuck or are working on a critical piece of work, you know that the team has reached the New Status Quo. Pair programming is now the new norm.

What’s Next?

Pair programming can be a powerful catalyst to spread knowledge and skill in the team. Engineering practices like Test Driven Development and refactoring skills can be diffused within the team during pairing. This reinvigorates the health of the project or the development of a product on hand. It is also a powerful way to bring new team members up to speed with the least amount of disruption to their work. However, just like a plant, the team needs to nurture and protect this practice continuously. One way it needs to be protected is when the team composition changes. It is important to set the expectations for new team members when working in such an arrangement. A good way to have an alignment is to add pair programming into the interview process. This allows the interviewer to assess the candidate’s skill and openness to collaboration, while the candidate can get a feel of how the potential new environment is going to be. It helps them to make a well-informed decision before joining the team.

Conclusion

When it comes to pair programming in a team, there is more to gain than lose. However, the benefits do not come cheap. Investments are necessary. There will be the initial cost of time when the team moves towards the new status quo. Teams and their sponsors need to look at how they operate and decide if they need these benefits. In most cases, it will be needed. It is in the stakeholders’ best interests to weigh the pros and cons, and recognise what they are giving up and the risks they are creating if they decide not to invest in this practice.

1. This does not magically nullify Fred Brooke’s Mythical Man Month law of “adding manpower to a late software project makes it later”
2. From Change Artistry (by Esther Derby, Gerald M. Weinberg, Johanna Rothman and Don Gray), Change Quotient “relates to how open a person is to change.”
3. Rubber Ducking : Sometimes the brain thinks too fast for its own good. Details may be skipped and assumptions are hidden. By explaining a problem verbally to a Rubber Duck (or in this case, you), the person is forced to slow down (you can only think as fast as you speak). By verbalizing it, the thought process is made explicit and assumptions are surfaced. This helps to bring to light more understanding about the problem. And the best thing as a Rubber Duck is, you do not need to say anything ! Just lend a listening ear. What an easy way to help remove an impediment.