Healthy, Pragmatic Pair Programming Guidelines

Published in

Practical Agilist

11 min readJan 4, 2019

In this post, I provide some references that explain the benefits of pair programming. Read them to help your team decide whether it’s interesting enough to pursue. I strongly recommend trying it out yourself though and provide some pragmatic guidelines for your team to follow to avoid common pitfalls.

Pair Programming Opinions, Surveys and Papers

This morning I attended an Agile Coaching Circle meetup in Columbus, Ohio where one of the topics we discussed was the polarizing concept of Pair Programming. You’ll find most people have a strong opinion about it. Some swear by it and won’t even work places that don’t pair. While others have had horrible experiences or are still just skeptical. Many managers in fact struggle with the commitment to put two brains on one keyboard because they feel like they’ll be half as productive. Anecdotally, you’ll hear there is *some* up front cost and impact to performance but that you make up for it in quality. Alistair Cockburn and Laurie Williams explain in their 2001 paper what amounts to an upfront cost of 15% (the overhead for two people working together at the same work station) with a 15% benefit of fewer bugs. On the surface, their research appears to suggest that in the worst case it’s a wash. However, they also argue that the negative impact of bugs is often bigger and more time consuming than the fixed upfront costs of pairing. They go on to refer to some of the other papers that cite surveys that show developers are often happier and more confident in their work as a result

One such survey, for example, showed that 94% of experienced Pair Programmers said they enjoyed their job better than programming alone [Williams et al. 2002]. And that 96% conclude that they were more confident in their solutions when they paired vs working alone. People enjoy their work more when they are more confident in their work.

The surveys and papers are excellent background reading on the topic (and surprisingly accessible and easy to read) however, first-hand experience is really the only decider. As a scrum master, manager or team member, you owe it to yourself to be open-minded and experiment with pair programming for yourself to see whether it can work for you and your teams.

Here’s the papers I’d recommend on pair programming:

To help make sure your experiment with pair programming has a better chance of being successful, please consider the recommendations below. Your team should conduct (or re-visit if necessary) a norming session to establish a working agreement of how your team has agreed to operate and behave. See which of these ideas resonate with you and your team and add them to your working agreement. There are many pitfalls and ways to screw up pairing. If you avoid them, and follow a few simple healthy guidelines, you’ll increase your chances of success and happiness with your team.

Be Respectful and Focus

First and foremost, it’s obvious this is a different way of working. The team should establish its own rules about pairing. Perhaps start with some core hours as part of your working agreement. You likely don’t want to expect everyone to pair 8 hours a day — you’ll burn out the team real fast. Pairing is effective, even in 4 to 6 hour doses each day. I’ve worked with teams that have a 10am standup and then only pair until 4pm. This allows for some flexible time during the beginning and end of day to do solo work, spikes or other work that may not lend itself well to pairing. (See Solo Work section below for more)

You should agree to be 100% respectful of your pair while you’re working together and that also means staying focused and eliminating all distractions. Close or silence all other devices and on your shared workstation, close email and turn off notifications. The only exception should be something like Slack if your team has included it in your working agreement (which hopefully comes with its own guidelines and etiquette around interuptions). It also means not having conversations with others or allowing your attention to drift to something outside the work you’re doing.

You should, however, be flexible about taking breaks. Pairing can be exhausting, so it’s important to recognize that anyone can ask to take a break anytime. But even with the right amount of psychological safety, it can be hard to actually open your mouth and say something so be sure to set a timer or some regular interval that you check-in with each other. Maybe even at the top of every hour, “Hey it’s 2pm, how are you doing? Need a break?” They key here is just open, honest and frequent communication. As you work more with an individual, you will learn how you combine to work as a pair and establish habits together.

Establish a Swapping Strategy

Some of the obvious benefits of pairing are knowledge sharing, better solutioning, and higher quality code. For this reason, you might consider pairing developers with QA engineers or senior developers with junior developers, etc. You won’t be able to form perfect pairs all the time, but as a team you’ll figure out what makes most sense for you at a given time. As you notice an important skill becomes dominant in one particular individual, it’s a good idea to swap pairs opportunistically with that person to help share the knowledge. One of the agile ideals (as unrealistic as it may be) is that everyone on the team knows everything and can do anything. Pairing does a lot to continuously improve your skills distribution toward that ideal.

When is the right time to swap pairs? Some teams like to swap after a big card is finished; some after each sprint; some choose a timeframe like a set number of days; and some pick the same day every week to swap, like during a Monday standup. Psychological safety is important on teams and even more important in pairs. Should anyone ever want to swap pairs, the team should try to accommodate regardless of schedule or impact.

As a team, you just need to agree on the intended frequency or strategy you’ll use to swap pairs. There will always be exceptions, so don’t feel bad if you can’t follow your plan strictly. Just remind yourselves of your intention so you are mindful of when you are off track. Your pairing strategy will become an interesting topic for retros: “How can we improve the way we’re pairing? Do we need to readdress our working agreement?”

Communicate and Be Humble

Healthy pairs will communicate a lot about the work they’re doing. They should discuss their approach on a new card before they dive in and they should discuss any challenges and decisions that come up along the way. Whenever possible, the one who knows the code you’re working on the least should take the keyboard. This ensures more communication. And the more the pair communicates about the problem they’re working on, the better the chance they’ll be happy with the way they’ve solved it and very likely with higher quality. As a pair, you should establish a rhythm and pass the keyboard back and forth frequently while you work. The right behavior here doesn’t allow anyone to get bored and ensures the pair both understand everything they’ve done together. Related side-note, during a traditional stand-up, only one person from the pair needs to speak, though both are welcome to should it be helpful or necessary.

For the person who might have more experience with the solution or a stronger opinion about how to solve the problem, they should consider pairing an opportunity to coach instead of being the hero. It’s important that everyone keep a very open mind. Even the most junior developers or the most non-technical person on the team will have an idea that will have tremendous impact for the team, if only you are open to the ideas and respectful of your partners as you pair. Remember, coding is not a race and the investment of thinking as you solution and communicating as you code are worthwhile because of the savings they produce in generating value for customers and reducing defects. It’s OK to pause and explore a crazy idea. If you’re doing it right, every single pair can learn something from each other.

Allow for Solo Work

As mentioned above, keeping core hours is helpful to control burnout. Pairing is mentally draining, being “on” all the time. Some people (extroverts?) may want to pair longer than the agreed upon window and if the pair agrees and feels good about it, they should be allowed. But for most teams, you will have the inevitable challenge of allowing for solo work to happen in parallel. This is very helpful for mental habits as well as the variety that many technologists crave.

Consider the following challenges and discuss with your team how you will handle them. There will be additional items in the work-in-progress state for the team. This can affect sprint commitments, flow measurements, burn-up and burn-down charts, velocity and everything about how the team measures its day-to-day productivity. These issues often work themselves out as long as the team allows it to become the new norm. Other technical and personal challenges can also be problematic. If the team uses source-control branching, the additional cards in progress can generate more complex merging and threaded development challenges. There’s also a certain level of maturity required to get good at context switching seamlessly (between solo work and pairing work).

Most developers enjoy having their mornings and late afternoons available for perhaps less intense work. Your team and its Product Owner may even start to manage your backlog differently or highlight certain cards that are more apt to being done solo than in a pair. It’s advisable to leave the most challenging work for pairs to tackle and leave sometimes tedious or smaller cards for solo work. Developers should still stick to some reasonable agile principles like only working on a single card at a time (one as a pair and one while solo). And no one should pick up a new card to work on until you’ve seen it through all the way to done.

Be Diligent and Prepared

As you’re working in a pair, it’s often appropriate to interrupt the flow with your partner to understand what you’re working on, to help correct a mistake as it’s being made, or to remind each other to write the unit tests! But there are other interruptions that you’re probably better off waiting on. You might get an idea to fix up some old code that’s near to where you’re working. Or you might spontaneously solve a completely unrelated problem you’d worked on previously. These rabbit holes are best kept to yourself until you have a break to dicuss them. For this reason, it’s a good idea to keep pen and paper handy to write down notes like these so you and your pair can stay productive on the task at hand.

Your team will have decided on the tools you’re using. But in some cases, pairing can introduce new tools that you might not be as familiar with. Some remote teams, for example, use different tools to screen share and communicate when not co-located. Whatever the toolset you’ve decided to use as a team, make a point to learn these tools so you’re not stumbling through the basics while working as a pair. You may even need some training before you’re ready to pair. If so, just discuss it with the team. It’s best if everyone has the basics down before getting started.

Prioritize the Team

As you become more comfortable working in pairs, it might become so comfortable that you lose old habits of conferring with the team on certain decisions that should be made as a team. One of the pair should keep an eye out for big enough architectural decisions, general design decisions or ambiguous requirements that need to be addressed mid-development.

There are other reasons too for the team to stop what they’re doing in pairs and swarm as a collective team. Production bugs or overlooked dependencies, for example. Be cautious about losing this team behavior. The team should still take priority, given certain serious situations.

Be careful to not let your old pre-pairing behaviors disappear. Things that require you to interrupt another team member like code reviews or interrupt the whole team for things like estimating exercises or other important meetings. Pairing should be a layer on top of your previous team behaviors. Don’t be afraid to keep doing the things you used to do. As much as we like to not be interrupted as individuals, it still needs to happen occasionally. The same is true for pairs.

Keep the Same Agile Principles

As stated above, what applied for you as an individual should also apply to you in a pair. A team should keep up their existing online and offline practices. The team should continue to keep JIRA (or whatever agile tracking tool you use) up to date during development as well as any physical board or information radiators. Those practices should stay intact.

Adhering to a definition of done is particularly important as well. If you require that every finished card be code reviewed and demonstrated to your Product Owner for acceptance before publishing the code, you should keep doing those things as a pair. New cards should not be started if all of the definition of done criteria have not been met on the previous card.

Conclusion

Pairing is not easy. But the benefits, should you believe the surveys, papers and anecdotes, are well worth the trouble. The only way to find out is to try for yourself. Hopefully, if you follow some of the guidance above, you and your team will be as productive (or more), better well-rounded in your skillsets, have less single-points-of-failure and ultimately be happier as individual team members.

If you enjoyed this, please clap or share. It means a lot to know my work on this blog is read and used by agilists out there in the world.

Hi, I’m Brian Link, an Enterprise Agile Coach who loves his job helping people. I call myself and my company the “Practical Agilist” because I pride myself on helping others distill down the practices and frameworks of the agile universe into easy to understand and simple common sense. I offer fractional agile coaching services to help teams improve affordably. See more at FractionalAgileCoach.com

How well is your team “being agile”? Our self-assessment tool focuses on 24 topics of modern ways of working including the Agile Manifesto and Modern Agile basics, XP, Design Thinking, Lean, DevOps, and Systems Thinking. It comes with deep links into the Practical Agilist Guidebook to aid continuous improvement in teams of any kind. Learn more at MakeTeamsAwesome.com

The Practical Agilist Guidebook is a reference guide that gives easy to understand advice as if you had an agile coach showing you why the topic is important, what you can start doing about it, scrum master tips, AI prompts to dig deeper, and tons of third party references describing similar perspectives. Learn more at PracticalAgilistGuidebook.com

Follow me here on Medium, subscribe, or find me on LinkedIn, or Twitter.