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.
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:
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.
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.
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.
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 :
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):
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 .
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.
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.
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.
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.