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.
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:
[Discussion moved to XpInaStrangeLand]
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
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 GoldOwners 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.
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.