Without courage, XP just simply doesn't work.
Communication supports courage because it opens the possibility for more high-risk, high-reward experiments… Simplicity supports courage because you can afford to be much more courageous with a simple system… Concrete feedback supports courage because you feel much safer trying radical surgery on the code if you can push a button and see tests turn green at the end (or not, in which case you can throw the code away).
Pair programming works for XP because it encourages communication… In my experience, pair programming is more productive than dividing the work between two programmers and then integrating the results.
If people program solo they are more likely to make mistakes, more likely to overdesign, and more likely to blow off the other practises, particularly under pressure.
There are times when problems simply can't be solved by the emergent brilliance of the team, encouraged by a loving and watchful manager. At times like this, the XP manager must be comfortable stepping in, making decisions - even unpopular ones - and seeing the consequences through to the end.
XP is a communal software development discipline.
The best environment is one of mutual trust.
Under stress, people revert to earlier behaviour, no matter how badly that behaviour has worked in the past.
Today's design should be done today and tomorrow's design should be done tomorrow.
Nerds aren't generally good at talking.
When you say one thing and do another, bad things happen. This book [Gerald Weinberg, Quality Software Management: Volume 4(sic), Congruent Action] talks about how to be congruent yourself, how to recognise incongruence in others, and what to do about it.