I think XP has some really deep, deep tacit assumptions going on, and I think the deepest tacit assumption is that we have a significant organizational problem, but we can't fix the organization. Essentially, the crap rolls downhill and ends up rolling right into the programmer's lap. When the product or the program turns out to be unsatisfactory, the fingers point to the programmer. XP is very well-intentioned; it's the software-development community beginning to say, "Hey, this is not only unfair to us, but it's not productive as a discipline and we can do a lot better." I applaud that sentiment and I agree with that sentiment, but then XP says, "OK, so, I can't change the organizational failings, so, I'm going to build my own internal defenses." I suppose this is probably better than nothing, but I'm interested in changing the way organizations are constructed. I believe that in order to create quality software, you have to change the organization. We can change the organization, and it strikes me that the assumption underlying XP is that the organization's structure is a given.
The problem is, you can't always fix the corporate structure and its infirmities - and yet, you still have to get something done. The reality - which Kent is bypassing in that first part of his answer - is that we aren't all consultants, and we can't all quit. He also makes a good point about customer-centric design (central to XP) here:
It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it.
Neither the people who buy software nor the people who use it have the capability of visualizing something as complex as the behavior of software. They also don't have the ability to analyze what appropriate behavior is.
There's a lot of truth in that. XP/Agile are an answer, not the answer. I still don't think much of BDUF, but Cooper makes some really good points here.