What to Do When Not Pairing

Source: Jeff Langr

Pairing is one of the more contentious practices in the XP canon. There are many ways to approach it, and many of those ways will result in disgruntled team members. Joining people at the hip for extended durations is a surefire way to kill interest in pairing. The same result occurs when you insist that people pair every hour of their work day.

A dogmatic stance (or even one that seems dogmatic) on any practice rarely works. People are good at finding excuses to avoid adhering to a new practice. To them, you're being dogmatic as long as you challenge their excuses. A better approach is to get the team to agree upon a reasonable rule, and then talk about a process for dealing with exceptions to the rule.

The idea behind pairing is that two people (and more over time) actively collaborate to solve a problem. It provides a form of review. Is it dogmatic to suggest that people must pair all the time? Absolutely! Is it dogmatic to insist that all production code is reviewed? Perhaps. That's a judgment call for your team to make. I would tend to lean toward reviewing all production code; even the supposedly simple stuff is easy to do poorly. But it's not my call, it's yours.

I have yet to see a shop that insists on pairing all the time. A better approach is to define what's appropriate to work on during times when you're without a partner. Sometimes, unfortunately, that necessarily will involve working on production code, but there are usually many other things that can come first. If you must work on production code alone, ensure that you solicit some form of follow-up review.

The card shows a number of things you might consider before touching production code without the safety net of a pair partner.