''I have a question. Do these challenges really mean to ask when a feedback-aware, process-modifying XP team will run their project completely off the rails? Or are they trying to ask something else, like "won't you need more documentation if your customers are in Singapore and you are in Pocatella?" --RonJeffries''

I (KeithBraithwaite) am interested in the ''possibility'' of the first. But I didn't write much of what's below.

WhatIsFail?

----

When will XP fail? Compare with ExtremeProgrammingBoundaryConditions These are circumstances when you '''really''' shouldn't use XP, in the opinion of the author, who is not one of the XP principals:

	* When the problem domain is not well understood. Why not then? Because your UserStories will be largely irrelevant or even counter-productive. So you very cleverly and efficiently build something worthless and misery-making. In this case you need to explore the problem domain first. 

''Sorry ,this is exactly when you should use XP.''

[Discussion moved to XpInaStrangeLand]

	* When you have nobody who can tell UserStories.

''I would guess that you can still use XP here.  Only you have to tell the stories yourself. --MarnixKlooster''

On the contrary. While I think the principles apply, the forces of XP could go far out of balance when there aren't two subgroups, one to define stories,assess business value, and define functional tests, and one to implement. I'd try to "WearTwoHats", but who knows what you'd really get. I don't see why any other process would work any better though. --RonJeffries

	* When you cannot change the interfaces freely, either because there are so many people on the project, or because they are using different languages.  Then you can't RefactorMercilessly.

Yes, if you can't refactor (most often because you have a requirement to publish your interfaces and allow other people to code to them), you'll probably need more design up front. You might consider two alternatives, however. First, consider doing an XP project internally to use the interfaces, find out what they want to be, and refactor them before publishing. Second, consider releasing the interface definitions incrementally. Could you use XP within the communicating groups?

	* When you cannot get regression tests, either because of concurrency / distribution or because people just won't write them.  Then you can't RefactorMercilessly.

There is no "people just won't". If we transform to "you cannot get regression tests because you haven't the balls or power to require them", then you can't refactor. You also can't test your design. Your project will be late and your software will be unreliable. But if you aren't going to test, please don't use XP.  --RonJeffries

Concurrency is an interesting case, as shown by ExtremeProgrammingChallengeFourteen. Does concurrency mean you shouldn't use XP, or does it mean you should use ConcurrentExtremeProgramming, which might be XP with some special handling such as reviews or program proofs?

''Is this page written by the XP people, or by someone else?''

Shouldn't have thought so. XPers admit the ''possibility'' of failure, under any conditions whatsoever? Nah.

On the contrary, rude one. Extreme projects should fail quite often, in the small. DoTheSimplestThingThatCouldPossiblyWork and SpikeSolution should result in failures quite frequently. If they don't, the solutions being tried weren't simple enough. 

Because XP is a light-weight HighDisciplineMethodology, XP projects will frequently go off-course. If all the feedback loops are in place, they should detect it and correct. If they've dropped some kind of feedback, they could get in deep trouble. With any discipline of development, the trick is to notice that you are off-track before the GoldOwner''''''s do, and correct it.

That said, there don't appear to be any ''facts'' here, so the page should probably be called WhenMightXpFail, but it would then be unclear how it would differ from ExtremeProgrammingBoundaryConditions. An attempt to approach the boundary from the other direction, perhaps? 

It seems as if there is a lot of wishful thinking/whistling in the dark on both sides of the to XP or not to XP "debate". So far, the only evidence presented on Wiki (ChryslerComprehensiveCompensation, VcapsProject) all clearly supports of the proposition: XP works.

Maybe I'm just perverse, but I feel that XP will be a lot more impressive as a methodology when there is a definite example of it failing, because then we will have at least one point on the boundary by inspection. 

Of course, that will require a truly heroic team somewhere to hang up their dirty linen in public. And it will also require XP ''to fail''.
Maybe that ''will'' never happen...

Any adaptive software development discipline, relentlessly applied, is unlikely to fail. XP seems no better or worse in that respect. Whether XP, as written, is the best methodology to apply in all cases, is certainly questionable. 

see AdaptiveDiscipline

It may be worth exploring the extent to which all CreditableMethodologies are based on the values of Simplicity, Communication, Feedback, and Aggressiveness.



ChryslerComprehensiveCompensation has discussed their small failures on a number of pages, most recently FallingFromGrace and HighDisciplineMethodology.