I think you've hit on something key here that is commonly missed.
Pair programming on its own doesn't add much value. It has to be part of a complimentary set of practices.
If you are working in an environment where detailed specifications are handed to you for implementation then there is little benefit to pairing. Its easier to just get on with it.
Pairing benefits design, not implementation. If implementation and design have been separated then those implementing will not find much benefit from pairing.
On 30 January[masked]:41, Wesley Hall <[address removed]>
To be honest, it is probably difficult to highlight any one event that changed my mind. I guess I would probably say that there was a growing recognition of the complimentary nature of some of the XP style practices and at a certain point they suddenly just seemed to click into place in my head.
For example, I have in the past, and still do on occasion, say that "if you don't pair program than it is a very good idea to at least do pair design". A pre-requisite for effective pair-design is dividing work into small chunks than can be dealt with (as much as possible) in isolation.
The next thing is to recognise that TDD done right really *is* design, and done really well is even documentation of a kind.