Pairing Styles

Overall, pair programming isn’t as controversial as you’ve heard. It depends on your styles of pairing. Some styles of pairing are very common, even among non-agile teams. They tend to be episodic, and last just long enough to get or give some aid. The good news is that they work. If a team views pairing with trepidation, these are common, non-threatening forms to start with:

• Rescue Pairing
• Training Pairing
• Brainstorming
• Experimenter/Researcher

Others are such bad ideas that they are rightfully avoided by all sane teams I’ve seen so far.  If you are considering pairing, and a team member balks, you should see if their mental model of pairing matches one of these styles. I suspect a team should decide that these styles will never be practiced personally, or tolerated within the team’s pod.  You have my blessings to object to pairing if “pairing” means:

• Worker/Rester
• Worker/Watcher
• Master/Slave
• Bully/Victim
• Writer/Critic
• Ball-and-chain pair marriage

And then there is the form of pairing that matters most.

• Peer pairing

Peer pairing is about two people who know what they are doing, who have skills, who are not stuck or lost or confused, designing and implementing ideas as fast as they can. A peer pair constantly vets ideas, tries alternatives, detects surprising failure modes, revises plans, teaches, learns, experiments, laughs, tests, commiserates, and grows together.  At least for a few great, exciting, exhausting hours.

The problem with peer pairing is that to the observer it might seem like rescue pairing or training. If you are always being trained or always being rescued, then you might seem like you’re not much of a programmer.  In this case, seeming is the enemy of being. A team may be so concerned about seeming competent by not pairing that they don’t increase their competence by peer pairing.  I suggest that this is a human foible, and we have to recognize.

When we talk about pair programming, we usually intend peer pairing (and the other good types at the top of the list), but people often hear us as meaning one or more of the bad types in the middle.

I hope to rephrase the question.  When you tell me you “don’t believe in pair programming” then I hope to ask you about the pair programming you object to.  Chances are I will feel the same way, and with that out of the way we can talk about the kinds of pairings we might actually try.