(This is the original submission from Agile 2008 - it was well attended, well received and, frankly, fun as hell.)

One of the most powerful and controversial agile practices is pair programming, or more generally, pairing. It isn’t controversial because its value is in question. We all know pairing, done effectively, reduces defects (by up to 86%, according to the 2000 University of Utah study), improves productivity (up to three-fold, according to the 1975 US Army study), facilitates career development along the lines of the generalizing specialist, brings new team members and junior developers up to speed quickly, spreads domain knowledge across the team and raises the team’s bus number. We all know pairing shortens time-to-market by reducing the time required for after-the-fact bug fixing. We can all relate to the old “two heads are better than one” phenomenon. No, that’s not why pairing is controversial. It’s controversial because a lot of people would just rather not do it. In the software development profession, that is a time-honored reason not to use proven good practices. Indeed, it is among our most venerated traditions.

Reluctance to pair is understandable, and there are many compelling agruments against the practice. For one thing, it creates impediments to high-priority work activities. How, for example, can we enjoy music on our headphones if we’re constantly engaged in design discussions with our partner? Another strong argument is a natural extension of the relative importance of processes and tools over people and their interactions. The reasoning goes something like this: DSDM and Crystal Clear don’t explicitly require pairing, and they are recognized, published agile methodologies. Therefore, pairing is not necessary. Ever. And we can still call ourselves “agile.” Neener neener! (Whew! What a relief. Now, where did I put my headphones?)

It’s hard to argue with that sort of logic. That’s why we aren’t going to. Instead, we’re going to focus on what’s really important: Bad pairing. Who can we blame for this, eh?

The Four Hoarse Men are (in alphabetical order by surname):

• Ryan Hoegg
• Lasse Koskela
• Dave Nicolette
• Brett Schuchert

There are so many reasons not to listen to these guys it’s hard to know where to begin. For one thing, they’re all consultants. That in itself is reason enough to run screaming from this session with one hand over your wallet. But there’s more: They’ve all been guilty of the bad pairing behaviors they’re going to demonstrate during the session. Yeah, okay, I guess you could call that “good experience” for this.

On the bright side: The group combines the wit, humor, and gregariousness of the Finns with the sophistication, charm, and cultural sensitivity of the Americans. I ask you: Where else ya gonna see that? Can we be serious for a moment?

If you insist. But only for a moment!

Pairing can be a highly effective practice that adds significant value to a project, or it can be a disaster whose cost far exceeds managers’ fears that they are just paying two people to do the work of one. In the worst case, you won’t get the work of one out of the two. They might even do damage that others have to clean up later. The challenge lies in the fact that working as a pair demands a level of attentiveness, collaboration, and continuous focus that working solo just doesn’t require. We want to demonstrate some of the behaviors that can undermine the value of pairing, solicit audience feedback about their own experiences and observations, and explain how and why pairing works or doesn’t work.

A few variations on pairing have become popular. Two general styles of pairing have emerged: The conventional driver/navigator style, and the so-called “ping-pong” style. There are also different ways to manage switching the members of pairs. Some teams switch frequently, others only on completion of whole stories. The pomodoro technique is another popular way to manage the timing of pair switching and to facilitate pairs getting into a state of flow. Some teams try to have the most-qualified team member handle each task, while others intentionally do the opposite.

Pairing originated as pair programming, which is the development of code by two programmers working together. As agile practices evolved over the years, pairing became more generalized and is now practiced across and between professional disciplines as a way of eliminating hand-offs and work-in-process inventories on agile teams. In terms of human factors, this sort of pairing is even more demanding than pair programming, since both partners must have some understanding of the other’s area of specialization in order to communicate effectively. Unsurprisingly, it is very easy to exhibit behaviors that confuse or frustrate your partner in a situation like that.

Each of these variations solves particular problems and introduces particular risks. If team members aren’t mindful of the strengths and weaknesses of the techniques they’re using, they may engage in behaviors that reduce or reverse the value of pairing. We hope participants will come away with a good understanding of what to do when pairing, and (the fun part) what not to do. More importantly, we hope they will have a better understanding of why certain behaviors are to be avoided, and how to recognize those behaviors as “process smells” when they observe them on teams. Process/Mechanics

The presenters will act out various pair programming scenarios while playing the roles of familiar archetypical personalities, including (but not limited to):

• Superman. He refuses to be impaired by a slow partner. He will hog the keyboard and save the world all on his own.
• Absent-Mind Ed. He’s distracted, sleepy, or preoccupied with other things besides the task at hand.
• The Back-Seat Driver. As navigator, he breaks the driver’s train of thought with a non-stop stream of trivial comments.
• The King of Shortcuts. As navigator, he mentions every keyboard shortcut the driver fails to use, but doesn’t make practical or meaningful observations.
• The Anti-Mentor. As navigator, this senior developer leaves his junior partner without guidance.
• Fearful Freddie. He refuses to refactor code he didn’t personally write.
• The Defactorator. He reverses refactorings others have done to make the code consistent with his personal preferences.
• The Soloist. He works solo as much as possible, and has a large repertoire of excuses not to pair.

They will also act out scenarios in general pairing, including (but not limited to):

• A pair cherry-picks interesting stories instead of taking the next card in priority order
• Neither member of a pair knows what to do, and they don’t ask for help. The rest of the team sees this, and doesn’t offer help. The ScrumMaster or team coach also sees it, and doesn’t intervene.
• Technical team member doesn’t know how to interact effectively with business customers or BAs
• BAs resist the idea of writing executable tests
• Testers resist the idea of pairing with developers to write test scripts
• Developers only want to “sling code” and resist pairing with team members in other roles or contributing to other tasks

In addition to demonstrating unhelpful behaviors of archetypes, the presenters will also act out pitfalls in different styles of pairing, including (but not limited to):

• Ping-pong pairing pitfall #1: Disengagement. The one who isn’t coding at the moment doesn’t do anything useful at all. He might even leave the room.
• Ping-pong pairing pitfall #2: Balkanization. Individual team members fall into a rut of always writing tests or always writing production code.

Throughout the session, the presenters will act out a scenario to demonstrate the effects of bad pairing behaviors in an amusing and engaging way (they hope). Through humor and exaggeration (but mostly exaggeration), they hope the counter-examples will stick in participants’ minds.

After each demonstration, participants will engage in an open-ended discussion to share their observations, ideas, experiences, and suggestions pertaining to the scenario.

Finally, the presenters will repeat the scenario to demonstrate effective pairing behaviors.

The session consists of a repetition of this cycle to explore as many scenarios as will fit in the allotted time. There is no lecture or slide show. The presenters just start misbehaving immediately.