OK so I had to go off to www.extremeprogramming.org and find out what it is all about.
On pair programming
Oddly, we have done a lot of pair programming in the past. It has been quite successful, particularly for debugging. It is a little problematic for contract work done on an hourly rate - as your client needs to be comfortable with it. It not only improves code quality, but must diminish the problem of adding more programmers to a project too. It also gives insurance against losing indispensable programmers. I imagine OSS projects tend to be more stable than companies, as you may change employers, but continue will probably continue working on your OSS project. Personally I quite like the idea of pair programming. I guess the OSS development (in the Bazaar) doesn't need pair programming as much, because additional "eyes on the code" are essentially free - so OSS projects are already achieving a proven high quality of code.
On minimising design/intermediate products
Someone suggested that many OSS programmers would have problems with this as they prefer the "Big Design Up Front" model. Surely even an XP project is based on someone's architectural overview/conceptual model of the problem space. I haven't that much experience with open source code, but I have found very little in the way of business analysis documents, requirements specifications, use case or class structure diagrams. Maybe the XP people are just following common practice (or OSS practice) here? I imagine XP developers may well draw class diagrams for those parts of a project which are complicated, or just in the process of coding a specific module, or negotiating an interface with another pair. But quality working code should always be the goal.