Something that often comes up when discussing the topic of pair programming is the notion of convincing management of its value. Am I paying twice as much to have two developers to work on a task instead of just one?
My experience with convincing management of the value of agile and XP methods has been if you deliver software on time and with few defects management will accept whatever practices get them those results.
The problem I often face and find much more challenging is how to convince other software developers of the value of pair programming. Getting comfortable with pair programming can be a challenge. The evolutionary nature of software development in an iterative, TDD environment means we don’t have all the answers up front. That can be an uncomfortable feeling. Nobody wants to look like they don’t have a clear vision of where the design is going or be uncertain about the best way to implement it. My advice is to get over it. The other person you are pairing with is in the same boat. When you switch seats and they are at the keyboard, they are going to be leaning on you to see the big picture and help guide the design.
Some people advocate code reviews and feel they can serve the same purpose as pairing. That is true in a sense, but one of the problems I have with code reviews is grasping the subtleties of the design and what trade-offs went into a particular design decision. With pairing you are intimately involved in the design, coding, and testing. You talked out the trade-offs as you went along. The tight feedback loop in pairing also reduces the likelihood of having to make a major refactoring that may come out of a code review. I am not opposed to code reviews, I just think pairing provides a better mechanism for good design and coding practices.
A lot of successful pair programming has to do with the two engineers developing a good working relationship and respecting one another. Talk through alternatives, try different implementations, write good tests, listen to one another, and learn from one another. My pair programming experiences have been some of the most gratifying development experiences in my career.