If your organization is like our organization, you were pair programming on and off long before attempting to adopt agile practices. Back then it was called mentoring and solving a difficult issue as a team.
For the last 6 months or so we’ve been using pair programming in a much more XP way on certain projects (driver and navigator, switching roles, etc.).
When the team is estimating work or tracking actual effort, there does not seem to be as much productivity gain involved as we had hoped. Usually the developers are saying, “Hey we like pairing, but I could do the same work myself in the allotted time and the other person could be doing something else.” One thing they all agree on is that when they are pairing they are less likely to be distracted by e-mail, phones, etc.
The biggest benefits from pairing so far seem to be mentoring and sharing knowledge, accelerated learning, cross training, better and more consistent design (depends on who the individuals are though), and perhaps reduced errors. For long running projects or products that will have a life cycle involving lots future changes and improvements, I suspect that the true benefits will manifest in the future. It could also be an experience factor or an imbalance of skills in the pair.
The literature (Pair Programming, XP Explained) seems to support 1+1 = 2 or 1+ 1 => 2. I think its achievable, I like to bet on a good team.
What is your experience? Does a pair always beat an Ace and a Jack?
