Last time I talked about how my team used Pair Programming on a several projects, how we found it beneficial to us, and a few of the downsides. But does that mean Pair Programming would work for you?
Proponents of Pair Programming do tend to love it, but despite how excitedly we describe it, Pair Programming is not always the best choice. Depending on your project, it can be costly, unnecessary overhead. Pair Programming has a higher up-front cost, and, depending on your specific situation, may also have a higher overall cost. The code is written faster, and higher quality, and thus will need less support in the future. But if that initial overhead costs more than what you’d save in the long haul, it might not be worth it. The old axiom says, “Fast, good, or cheap: pick two.” Pair Programming chooses fast and good over cheap.
Pairing (or even Swarming) is most effective for teams that are implementing something new and innovative where unique challenges might want inventive solutions. If your project isn’t innovative, if you’re just expanding on an existing code base (e.g. adding a new tax code to a database or a new language to an interface), then Pairing would be a complete waste. If the work is so straightforward that the navigator in the pair never sees anything to contribute, then they’re better off working a different task on their own.
Covid-19 demonstrated that open or crowded working spaces, such as in-person pairing, can spread viruses. However, many applications make the old “two keyboards on one workstation” model unnecessary. Screen-sharing and multi-user editing applications make remote Pair Programming easy, and there are a lot of great tools out there for all platforms, styles, and budgets. Here are over a dozen: https://www.makeitinua.com/posts/13-best-tools-for-remote-pair-programming-in-2020
Potential Pitfalls of Pair Programming
When implementing or trying out Pair Programming, keep an eye out for these indicators of potential problems.
Disengaged pairing partner. Be mindful if one member of a pair is disengaged or distracted, particularly the person in the observer role. They might have their own machine to do research (a very valid pairing activity) but they shouldn’t be checking email or social media unless the pair is taking a break or waiting on something (like automated tests) to finish.
Silent pair. Pairs should communicate almost constantly. There can certainly be stretches of silence: basic framework is being typed in, code is being compiled, tests are being run, etc. However, overall the two engineers should constantly discuss how they’re implementing the work at each step. This is especially true when Pair Programming is combined with Test Driven Development.
That said, I also let my team decide how to do their own work. I’ve seen very silent pairs that were extremely productive, with both partners fully engaged. They were just in tune enough that they did most of their “communication” on the screen. Silence is an indication of a potential problem, not proof of one.
Teacher / student roles. Pairing an experienced engineer with a novice is a quite common practice. Even when it’s not intentional, one member of the team often knows more about a topic than the other. It’s easy to fall into a habit where the experienced person does all of the work, leaving the novice only to watch. This can result in the senior engineer working without explaining and a novice who is too uncomfortable to interrupt them or ask questions. Even if the novice is engaged and learning, they may not feel they are contributing to the project.
Tips and Tricks
There are ways a team can make pairing (and other similar activities) a little easier.
Cut distractions. Pair partners should block pairing sessions out on their calendars to prevent interruptions. Scrum Masters and managers should reserve meeting-free blocks of time to make that possible and protect the pair from potential outside interruptions. Pairs can socialize a bit during pairing sessions (people work better together when they are relaxed and know each other) but that isn’t an invitation for someone else who’s not part of the pair to join in.
Time-box pairing sessions. Set a specific time box for each pairing session. Have the engineers switch roles either between every block of code or every 25 minutes. Do a stretch break every hour or so and keep each overall session under 3-4 hours. Working remotely can be even more taxing (and more vulnerable to distractions). Pairs working remotely together (especially wearing headsets on video) should definitely take breaks every hour or two. Also, if possible, rotate your pairing partners between every session or each day.
Have the novice engineer drive. Expert engineers may be tempted to keep novices in the observer seat. When you have an expert / novice pair, not only should you ensure that the novice gets to be in the driver’s seat, have them spend at least half their time there during the pairing. It may slow things down a bit, especially if the expert has to dictate parts of the work, but the novice will learn more quickly and likely have a better overall experience.
I was that level of novice in a pair once, coding an area I wasn’t familiar with. Luckily I type fast and could keep up with my expert partner’s train of thoughts on the keyboard.
Avoid forcing pairs that don’t work. Some people just don’t work well together. They may function fine on the same general team, but just not mesh well for the closer work needed for Pair Programming. Don’t force two people who don’t get along to partner up, or you’ll feel like you’re in a bad high school sitcom. Accept their differences and let them choose other partners. If nobody on your team pairs well with anyone else, then your team probably has other issues.
Discuss how pairing is going during your Retrospectives. Even teams that have done Pair Programming for a long time should periodically self-analyze and check in on how things are going. Silent resentment can build up surprisingly quickly and sour the experience, and it’s vital to have psychologically safe open communication between pairing partners. Retrospectives are a good time to air out those issues. The milestone is done, the focus is on changes already, and the Scrum Master is there to help mediate and keep discussions healthy and supportive. Not every pair works well together, and not every version of pairing works well for every team. Encourage people to say what they wish could change, then experiment and see what changes you can make.
Pair Programming, as much as I love it, has work it’s well-suited and poorly suited to, and it has its drawbacks and pitfalls. And remember, if you’ve never done it before, Pair Programming feels weird and uncomfortable at first. This is all to say, there will be growing pains. However, pairing is a great tool to have in your Agile toolbelt, provided you know how to use it. A motivated, prepared team can anticipate and avoid many of them, and often find ways around whatever surprises they miss.