I won't lie. They are difficult to overcome. I really advocate going a full XP style if you are going to do pair programming. Getting really good at TDD make

I won't lie. They are difficult to overcome. I really advocate going a full XP style if you are going to do pair programming. Getting really good at TDD makes such a huge difference. You can drill down into one aspect of the design and build it up -- because you are isolating it, it reduces the amount of conversation necessary. You can say, "How about we start with object X and see where it takes us", even if you have a pretty good idea where it's going to go. Those who are lost are given something to hang on to and focus on. But it's also important to be flexible because often you have a whole architecture in your mind and your pair starts taking it in another direction. It's good to allow it to move forward, checking in code as you go, without fear that it's all somehow going to be ruined. On my team, I often say that I know exactly one way to be really, really successful -- XP. There are other ways to be successful, I'm sure, but that's the way I know how to do it. If you start mixing and matching techniques, it gets harder and harder to find a path towards excellence -- because you are walking through the unknown. Although I'm a huge advocate for pair programming on an XP team, I don't really recommend it for other types of teams because I don't know how to make it work well. (Just to be clear, I can be successful using other techniques, but the kinds of success I've had on highly functional XP teams, I've never seen anywhere else before)