Obie Fernandez writes a blog post about how pair programming is not for the masses.  I find it interesting that his post addresses many of the items that were not discussed at the Agile 2009 session on how to debug pair programming.

Three ideas identified by Obie are common stumbling obstacles I have observed when trying to consistently use pair programming with product teams:

1. Most software people don’t understand pair productivity: unfortunately this is so true and it applies to both management and programmers.  From the management perspective, I cannot understand why pair programming is not embraced more fully.  You get higher quality code and the programmers are focused on doing work (as opposed to reading the Internet or working on side projects).  For the programmers, pair programming just makes the work more fun and less frustrating.  Granted, pair programming is not for everyone, but when coaching teams on this practice, I insist teams try it out for 3-4 weeks and learn what the boundaries are.
2. Most software managers don’t want to invest in the necessary hardware: if you do not understand the value of the practice, you are not going to invest in tools that make it easier.  And yes, pair programming is an investment in the future quality of the system.  If you invest in something, you are serious about it.  Or put another way, put your money where you mouth is.  Spending a few thousand dollars on good machines gets people’s attention.
3. Most software shops are not configured for pair programming: if you are not going to invest in tools and do not understand the value of the practice, why would you fight the office furniture police?  Why be a squeaky wheel in the corporate world if you don’t believe pair programming is valuable?  Management investments in the environment are cues workers use to know if management are serious about changing the development practices.  Nothing says change more than tearing down cubicle walls.  Being able to do that shows you have management support and goodwill.

So, what is the solution?  I am not really certain I know the answer since solutions are context sensitive.  I believe some of the prerequisites are maturity within the developers, desire for code excellence by all parties and an open mind.IF we have these prerequisites in place, then we can begin to have a conversation.