We often find someone being the odd man out.  How do we handle it?  Lots of ways.  Usually, the 3rd person does some sort of exploration or other non-production code sort of thing.

However, we often find that we often get to the point in exploration where we are producing something useful and transitioning into production code.  When we do, we find a pair who has been at it a while and interrupt them by asking if one of them can temporarily pair with someone else.  Often, we find that they are not far from a stopping point, or they are just wrapping up something, or are about to enter ExplorationMode themselves.

So, we make sure we don't go too far out of ExplorationMode and into ProductionMode without TwoSetsOfEyes looking at what we are doing.  A PairPartner gets up from what they are doing temporarily and checks out what the maverick is up to.  Sometimes, they quickly ask "You Got A Test For That?" and, when the maverick offers a sheepish grin, go back to their original pair.  Other times they help them form the test and/or write the code.

The person (of the original pair) left behind will only go so far until they realize they are in trouble (or the PairPartner who left may suspect it).  They get hooked back together with their original PairPartner before they cause too much damage.

This works when we all have a healthy fear of what happens when we're not PairProgramming.  This means no one is working by themselves for more than an hour at a time or so when there is an odd man out.  If we all use the general rule of asking ourselves whether we need a PairPartner every 15-30 minutes or so, things work fine... we don't end up in the grass (or ditch) at the side of the road.

I wouldn't recommend this on teams where people don't believe that programming by yourself is a bad idea.  So far, it works pretty well for us.  But, we'd rather be PairProgramming. -- KenAuer


At Axys Solutions, we are doing some collaborative development with our client that has been scoped at 3 developers, or as I like to call them, "progs" :). We have decided to adopt a technique known as [ProgrammingByAttentionDeficitDisorder, as one team member calls it, although I prefer] OddTeams, which is a rapid precession technique for reducing the risk and difficulties associated with having an odd number of developers. I would love to hear thoughts on this approach -- see OddTeams.

- JefNewsom