In WhenXpFails and similar pages, folks explore how an XP project might go off the rails. I'm sure that if someone here were actively supporting the CMM, they'd be asking the same kind of questions.

What do we mean. WhatIsFail? Let's discuss some kinds of project failure to which XP might be more vulnerable than [your favorite methodology here]. The assumption here is that the project is actually following the XP rules.

'''LingeringDeath:''' The project goes on and on forever in that nearly done state until finally in frustration and desperation the GoldOwner''''''s cancel it.

An XP project is supposed to redo and report its CommitmentSchedule every couple of months. If the project is not making progress, the schedule will show insufficient change from one to the next. GoldOwner''''''s will get to see what is happening and take action.

Is it possible that no progress will be made? Sure. Make a subheading.

'''Poor Release Quality:''' The software is allegedly getting done, but it never really works. Releases are made and then discovered to be buggy.

An XP project is supposed to have FunctionalTest's for everything that needs to work. It is supposed to show the graph of tests running vs time. If it doesn't go up, GoldOwner''''''s will get to see what is happening and take action.

Is it possible that quality will be low, so that release is not indicated? Sure. Make a subheading.

'''Beaten by Competitor:'''
Somebody else's product is better or delivered sooner than ours. A market failing to mature has the same effect.

XP specifically focuses on building a complete system ASAP, maximizing business value provided early. Is there a methodology or approach that performs better in this environment?

'''Lost identity:'''
It's a consumer product. The GoldOwner''''''s are the only "Customers" available. They never quite make up their minds about what they want. The team endlessly builds infrastructure for a product that never comes into being.

If customers won't say what they want, XP can't execute at all. If they change their mind, the project will thrash, because XP says you do what they ask for. (It doesn't say you can't point out their folly, but you still do what they ask.) If there an approach that would perform better in this environment?

'''Canceled:'''  
Executive says, "I disagree with the way you are working," and either kills the project or mandates you work another way.  Alternate scenario (B) is that it turns out your user/customers weren't reliable, and after you put out the first releases, everyone discovers you built the wrong system.
* Alternatively, the attempted concept doesn't work and can't work.  "Yeah, that wireless power transmission seemed like such a good idea at the time."