A good paper on pair programming from Laurie Williams, of North Carolina State University here. It is very telling on both the nature and the value of this practice, and emphasises two aspects of it that I feel have yet to be appreciated.
Firstly, pairing is a practice that can be reused all across the development and delivery process. We routinely use a version of it in Agile backlog refinement (when the whole team gets to review the backlog), and it’s plainly implicit in one of the true fundamentals of Agile, namely collaboration. It is striking how much pairing relies on the high levels of experience, humility and professionalism on which Agile rests as a whole too.
Secondly, Williams emphasises the way in which pairing introduces, almost by the back door, a non-Agile practice that was always neglected by traditional lifecycles, namely the review. Yes, there are zillions of reviews going on all the time, but in my pretty broad experience they don’t have the impact they should. Of course, formal reviews don’t sit very well with Agile, but it is impressive how pairing brings peers together for exactly the purpose they strongly resist when asked to do it in the form of a review as such.
Finally, pairing is an excellent way of preventing the growth of technical debt, and as such it is such both a boon in its own right and a serious economy in the process as a whole.
So a treble win for pairing. And probably a lot more too, if you look careful at its links to other Agile practices.