Something I’ve discovered during team interviews for Agile Maturity Model Assessments is that a lot of people misunderstand what Pair Programming actually is. As a former skeptic who’s now a real fan, let me explain—and encourage you to try it out.
A lot of people I’ve talked to think Pair Programming just means two or more developers working on the same user story together by splitting up the work between them, with each person working on certain tasks: maybe one writing test automation while the other creates functional code. While that is a perfectly reasonable way to implement a User Story, it’s not Pair Programming.
Pair Programming originated with Extreme Programming (or XP). Surprisingly, given some of its radical (or extreme) techniques, Extreme Programming is one of the earliest Agile software development methods (even predating the Agile Manifesto). How extreme, you ask?
In Pair Programming, two programmers work together at one workstation on one task. One (the driver) writes code while the other (the observer or navigator) reviews each line of code as the driver types it, considering it and offering ideas for improvement. The two switch roles frequently throughout a coding session. In fact, XP recommends that both people in a pair have their own keyboard and mouse, so that the swaps can happen fluidly, almost reflexively, encouraging the pair to exchange ideas within the code. “Oh, yeah, but we’ll need…” type type type “Ah, yeah, but then that changes the scope of…” type type type …and so on.
I had the privilege of working on several near-XP projects early in my career as an Agilist. While we couldn’t apply all of XP’s practices, we got quite a few, including Test Driven Development and Pair Programming. My team decided that all production code must be written in pairs. Partners switched roles at least every hour, and the pairs themselves changed too, between tasks or after breaks. It was a team of only five developers, so we set up two pairing workstations in the middle of our lab in a separate area from the team’s desks. Unpaired people worked on expanding test automation, writing documentation, investigating bugs, doing research, refining our backlog, and myriad other activities that came up (the inevitable shoulder taps, for example).
One might think that putting two people on a task together meant we completed less work each sprint. In fact, our pace sped up significantly once everyone got used to the rhythm of pairing because our developers rarely got stuck any more, or at least not for long. When you’re coding (or, frankly, doing many activities) by yourself, it’s easy to run into a problem and lose time finding answers. When pairing, you have someone else there to bounce ideas around and solve problems with. Often, that second person can even see trouble coming and help you avoid it entirely.
We no longer had to do formal code reviews (since pairing is a form of review). Partners keep one another from missing anything. Our bug counts plummeted. Regression issues (working code breaking due to new changes) were nearly nonexistent. Our clients were thrilled.
Pairing also made our team more fungible—nearly anyone on the team could confidently write code in nearly any part of the code base. Swapping people around so often, it just happened naturally. Since nobody wrote code in isolation, multiple people knew even the most obscure corners of the project. Everyone on the team was constantly cross-trained, and thus (while developers might have their own specific expertise or skills) specialists were never a bottleneck to work or investigating an issue.
In addition, that cross-training effect helped bring new team members up to speed faster than we expected. In fact, in some cases I was surprised at how well things went for pairs of significantly uneven experience. I figured training would be good for the novice in the pair, but it was often helpful for the experts too. Talking through things out loud actually sped things up and revealed bugs and other issues that might otherwise have slipped under the radar.
This all isn’t to say there weren’t challenges when we implemented Pair Programming.
First of all, it’s…well, it just feels weird. What am I doing? My job is to sit here and watch you type? No. No, that can’t be right. And really, if that’s all you’re doing, then you’re not properly pairing. But especially at first, that’s how it can feel. There’s a self-consciousness that probably comes from doing this strange new thing with another person there, sort of like trying to dance. There’s an art to it. You may have to try it several times (and maybe swap pairs around as well) before you begin to find the rhythm.
Second, Pair Programming can exacerbate differences in working style or personality. I spent more time than I expected arbitrating debates over which development environment or coding standard was best, and even what time pairing sessions should start. Pair Programming demonstrated to everyone on the team why a clear, thorough, and consensus-driven Working Agreement is a key tool for an Agile team’s success. There were also a few pairing combinations that we, as a team, agreed to avoid. I was really pleased that all my developers would work with one another, but when two people truly do not enjoy working together, I found it best not to force them to.
We regularly reviewed Pairing in sprint retrospectives, and each time the team agreed that Pair Programming (and our other XP practices) were beneficial and even enjoyable. Several of our developers were introverts who struggled at first with the nearly constant interaction that pairing required. Yet none of them regretted the experience. I remember one of them telling me, “I’ve never slept as well as when we started Pair Programming!”
Pair Programming may be an old technique, but it’s still revolutionary. While it’s challenging, it offers real and sustainable benefits to a project’s delivery speed and reliability, can help you integrate new team members faster, and can prevent development bottlenecks. If you have the space for a bigger than usual experiment in one of your sprints, it’s well worth trying out.