Avoiding pair-programming breakdown

One of the persistent themes in my team’s retrospectives is that we don’t pair as much as we should. It’s not that we don’t want to pair, or that something’s stopping us: we just seem too often to lack the discipline to start pairing and then not drift back into working alone again. I’m not sure the best way of avoiding the delay in forming pairs at the beginning of the day and after lunch¹, but here’s at least one tip to keep the sessions going.

If you need to quickly nip back to your own machine to check some documentation, google something, check for some urgently-awaited e-mail reply or whatever…

Don’t take your chair with you.

¹I think this is a variant of the ‘one more pint effect’ that’s often observed when a group over a certain size meets in a pub prior to going for a meal. One person decides that everyone’s going to take ages drinking up, so they decide to have ‘one more pint’. Of course, someone else then sees them with a full glass, and makes the same decision, and you end up arriving in the restaurant an hour later than planned. The pairing equivalent is where you all think ‘everyone looks busy, so I’ll just [answer that e-mail | do that pointless mandatory on-line training course | go and make a coffee] while I’m waiting for someone to pair with’.

Of course the real answer is to be strict about all production code being pair-programmed, rather than letting yourself make exceptions for ‘trivial’ tasks, or UI code, or refactoring, or something that started as a spike but has somehow grown tests and made it into the trunk…