5 Tips for Introducing Pair Programming

I once saw a manager require full-time pair programming on their team, only to watch 20 highly skilled developers quit within weeks. Needless to say, not everyone wants to pair. If you are looking for a low-risk way to introduce pair programming to your team, here are 5 tips that can help.

Tip #1 - Start With The End In Mind

Pair programming is a means, not an end. It's "the thing that gets you to the thing."? Your real goal is probably something like improved DORA metrics (higher quality code, faster releases etc.) or lowered continuity risks. I recommend making these goals clear, and recommending pair programming as an experiment that might help you achieve them.

For any change of behavior to be successful, people must feel motivated to change, and two of my favorite books in this area are Why We Do What We Do and Self-Determination Theory. They make the case that how we achieve goals is as important as what the goals are, so I recommend holding regular retrospectives with developers and responding to feedback. Stay open to the possibility that you can achieve all of your goals without pair programming.

Tip #2 - Meet People Where They Are

Many factors influence people's satisfaction and productivity when pairing, including introversion/extroversion, neurodivergence, work schedules and language barriers. The developers on your team fall somewhere along a spectrum of opinions about, or interest in, pair programming. How you introduce pair programming will depend largely on where you're starting from. Start by taking a quick poll about where people put themselves on this spectrum:

If most of the team is on the more enthusiastic end of the spectrum, you can probably just start right away and figure things out as you go.

If developers are less interested in, or even opposed to pair programming, I'd recommend starting out with structured workshops led by experienced instructors and setting less ambitious goals like "we'll try pairing for 1 week."

Tip #3 - Train Developers on Pairing

Pairing is a skill, separate from software development. At the start, make sure everyone has been introduced to popular pairing strategies. If everyone on the team has a shared vocabulary around techniques like ping-pong, driver/navigator, chess timers etc. then they are more likely to have a positive experience.

Make sure these initial training sessions cover how to maximize the effectiveness of pairing. For example, when there's a big skill gap between two developers, it's often better for the more junior developer to "drive" (hands on the keyboard) to avoid a scenario where the more senior engineer is both talking and typing. These aren't obvious at first, and having a skilled instructor/coach to explain things upfront can make a huge difference.

Tip #4 - Rotate Often

In my experience, pairing loses value when there's little or no rotation. As "pair marriages" form, the social pressure to follow codebase norms decreases, and people's ideas tend to converge. Having fixed pairs for long periods of time also leads to less knowledge sharing.

To start, I recommend switching pairs every day. A great time to decide who's pairing with whom is at standup in the morning. If backlog items take longer than a day to complete, one developer would stay on the backlog item from the previous day, while the other one swaps out.

Tip #5 - Create a Supportive Environment

There are two crucial parts to the environment surrounding pairing: the physical environment and the team environment.

Setting up a physical environment is fairly easy. For in-person pairing make sure developers have two keyboards, two mice, and two monitors connected to one computer. For remote work, make sure all developers have CodeWithMe or LiveShare set up so that both people can code, run code, view the browser, run tests and see terminal output.

Creating a supportive team environment is a little more involved. Make sure that Product Managers know that the work-in-progress (WIP) will be cut in half. It's also normal for there to be a dip in velocity when changing team processes, so be sure to communicate this to internal stakeholders.

—

Pair programming can be wonderful or terrible for your team, and by following these tips you'll increase your chances of it being a positive experience.