Pair Cliques

Kent and Ron have said this is bad bad bad, but aren't there occasions for it? Sometimes there's no choice - the work demands certain timeframes and certain skills, there's a rush on, and you just want the best people for the job. No?

I have this problem at my work. CollectiveCodeOwnership is hurt because this clique knows this part, that clique knows that part. It feels less like a whole team effort because the team is divided. The code suffers.

Also, we sometimes have little 'RefactoringWar's' ... good grief!

Sure, if a task needs a skill that I'm a hot-shot in, grab me for the task, but for goodness sake, mix up the pairs and spread the knowledge! Cross-pollinate! PairPromiscuously!

This is a classic trade-off between short term and long term gains. In general, PairPromiscuously early in the release cycle, when the benefits of cross pollination will have time to acrue. When you get into late release pressure - particularly if certain people are rolling off - make sure that you pair the right people for the beginning of the next release, but there's no sense in pairing two people rolling off the project together for any reason except speed.

PairCliques can improve velocity dramatically in the very short term - a couple weeks, maybe even a month, but PairPromiscuously's benefits will outweigh the velocity gains in about that time frame. This is the very reason that it is often very difficult to sell PairProgramming to managers. They have likely frequently experienced the speed up from getting the *right* people together in the short term, but they probably haven't seen the benefits of a generalist team that can work on all parts of the code.

-- JeffBay

CategoryPairProgramming