This title seems rather inflammatory. Couldn't it be renamed to XpCriticism? or something?
articulated many of the same concerns I had when I read the book and before the Great Failure that is this current client's attempt to "do XP." Some of his positions may be a little overstated, but he is by no means a frothing-at-the-mouth XP hater. I may come back to this page and fill in some of the reasons why I can see that the XP mold doesn't fit the bulk of the industries I work in. Perhaps that will lend a little more credence to the arguments he makes. Go Sunir! -- MartySchrader
Could you tell us in what ways the "attempt to do XP" that you are referring to is a failure, and what the causes appear to be ? Just this particular case, as opposed to a more general analysis of why it doesn't fit the industries you work in. Thanks.
Perhaps it would also be interesting if critics of XP could point to some concrete examples of failures (as its supporters have pointed to at least one
example of its success) rather than resorting to FUD tactics which include general hand-waving and agitation. Many people here would be very interested in seeing the faults that XP has (not least KentBeck
and others from the C3 team) but let's please do them (and ourselves) the courtesy of using real-life facts and not vague suppositions.
I would urge caution here. Marty above refers to a failure in attempting to do XP, not to a failure while doing XP. The page title is a misnomer. Sunir's remarks in CritiqueOfXpxec address a putative failure of the people defining XP to clearly delineate the situations where XP is applicable from those where it isn't.
Marty's remark appears to suggest a different sort of criticism - that as a result of those poorly understood boundaries, an attempt to adopt XP in an industry where that isn't appropriate is resulting in a "Great Failure".
- C3 failed. More on CthreeProjectTerminated.
You're right, because IfXpIsntWorkingYoureNotDoingXp
- I would prefer to wait until Marty has told his story before commenting further.
- I agree. My point was this last comment was completely the wrong answer. The original response to Marty was completely the right answer. It's better to engage the person and his team whose project failed in a dialog than shut them down as being failures themselves. My second point is that this wrong response is the most common response of XP advocates, which is why "XP" is useless (whereas the NonMethodology? isn't). -- SunirShah
It is worth pointing out that Marty himself advocates a methodology (though one other than XP), which, I respectfully submit, somewhat undermines the tail end of your second point. As to the main body of your second point, we have argued it elsewhere - apparently inconclusively - but I think restating it on this page was uncalled for.
I think it is useless to bring up the label "XP" in most cases because (apparently) most people don't or can't really do all of XP. I think XP as a template is useful, and I'm glad it has a name. But if you wish to remove these remarks to tighten the focus of this page, go ahead. -- SunirShah
My comment above ("I would urge caution") was in response to the request that "critics of XP [...] point to some concrete examples of failures". The reason I wanted to make the distinction between "failure to adopt" (which I think is what Marty is referring to) and "failure despite having adopted" is that IMHO we can only be asking XP critics for concrete examples of failures of the second sort. If Marty is indeed referring to a failure of the first sort, then it is useless and misleading to request concrete examples of the second sort.
As an analogy, think of a new way of teaching people how to drive. Extreme Driving doesn't involve learning to operate the clutch, which side of the road to drive on isn't explicitly discussed, etc. Nevertheless, it is claimed that this way is better than the old way. Now, some students might have the following problem : "I can't even get the car out of the garage, I just can't figure out what to do". Other students might report a different problem : "I was driving the way you told me, got into a crash, and am now paralyzed from the neck down".
I think everyone would agree that the two kinds of statement identify different problems, and that appropriate responses to either kind would have to be of a very different nature. If Marty's client is stuck in the garage, it doesn't help to say that critics of XD should point to concrete examples of crashes by students who learned with XD.
It seems to me that Marty's case is a hybrid. "The driver tried to drive your way, even though he was on a racetrack and you always said it mightn't work for racing, and it all went horribly wrong and we had a terrible smash-up."
It's ok (and good!) for XP to not be appropriate for certain environments. For example, as demonstrated on UnitTestsReconsidered
, there are some applications that UnitTest
ing cannot cover. Since XP qua XP requires UnitTest
s, XP itself isn't appropriate. It would be nice if XP people would find out ways to adapt to other environments, but that idea isn't gaining traction. So, maybe we should "abandon" XP and move onto something else. Anyone up for Totally Intense Programming? ;) -- SunirShah
Any person or group trying a new way of doing things, such as adopting all of XP's practices when none of them were practiced before, is likely to experience a slow-down until the new way becomes automatic. If they expected immediate improvement in productivity, this slow-down will appear to be a failure. Then, if they don't have a coach or committed advocate, it is likely that a group or persons in the group will fall back into old habits.
XP is a high-discipline, low-overhead methodology, which will be hard to adopt by persons and groups with low discipline.
By the way, I'm not entirely sure what the "great failure" of XP is. Would someone care to elucidate? I believe XP and "XP" have been incredibly successful. I think it has the same problems of any branded methodology. Last night, I met a statistics methodologist. It's hilarious to hear the similarities in carictures between methodologies of different fields.
As to the failure of C3, you will note that the failure was blamed on external forces. This is common in many "XP" failures. Similarly, I think many successes are due to external forces. This is because XP only defines a system of solutions for a small subset of the process. There are other problems it doesn't come anywhere near to addressing. This was my point on XpAndOfficePolitics
A competent methodologist is an expert in all the management facets. She knows a great number of patterns and pattern languages, and a great number of system solutions. As the anonymous author aptly pointed out, low discipline developers will fail using XP. They will fail doing WaterFall
too, or the RationalUnifiedProcess
. They will likely also fail doing anything else.
Getting people to be disciplined is a tough managerial problem. In fact, it's one of the oldest, running back in modern times to SigmundFreud
. I wish I knew the answer. It's really hurting my current attempts to introduce XP inspired practices (*) where I work.
(*) I believe it's impossible to do "XP" unless everyone is onside. This is one serious problem with adopting XP. If someone has experience successfully introducing XP into an unconvinced environment, I'm interested in hearing it. (Of course, there's AdoptingXp
.) And, yes, this is my main criticism of XPXEC: it's unconvincing. -- SunirShah
It seems that XP only works in an environment where all the factors are in its favor. The single overriding factor, of course, is management buy-in. As with any other methodology for anydamnthing, if the client's management doesn't want to "do XP" then it won't happen. Certain portions of XP can be implemented as standalone aspects of development, but the implementation of XP as a complete methodology needs to be complete
to be successful. This is what I observed and I am sure others have seen the same thing. -- MartySchrader
Am I the only one who sees the irony in a claim that "the implementation of XP as a complete methodology needs to be complete to be successful" on a page called GreatFailureOfXp? Sorry Marty, but I've watched a gazillion methodologies come and go since 1980. In my experience, this claim is the surest sign that the methodology has died. It was a fun ride -- XP is dead, long live XP. -- TomStambaugh
Wait a sec, Tom -- I am not
a bomb-throwing Anarchist supporter of XP. I am just saying that, having read quite a bit about XP from both sides and having been in a shop that proclaimed XP as their methodology I can see that XP needs a complete support structure to perform as advertised. I can see that XP can
work, but it certainly didn't "work" in the environment I was exposed to. Management never bought into the need to set up the physical environs nor use customer feedback nor set short iteration dates nor any of the other primary practices of XP. That being the case, how the hell do you expect XP to do?!?
Keep in mind that this particular client immediately replaced their XP thinking with Fagan Defect Free Process thinking. (Jumping from one school to the next.) For a short period of time they actually did
do the Fagan inspections the way he taught us how to do them, and I saw amazing results. However, within a couple of months management started trying to "shortcut" the inspection process and totally ruined everything by doing so.
After that they went to Critical Chain. After that they tried something else that I have forgotten. At any rate, the point is that absolutely nothing
requiring discipline will work if the discipline is not maintained. This is true of diets, military organizations, and methodologies. -- MartySchrader
Marty, I didn't mean to imply anything about you, or even XP. I meant only to highlight, quite specifically, your statement that XP only works if it is "completely" implemented. Further, I suspect the two of us may coming at the very same conclusion, albeit from different perspectives. Many -- perhaps even most -- of the "gazillion" methodologies that I've seen in the last 25 years do, in fact, work very well when "completely" implemented. You cite several examples here. It seems to me that a key aspect of our industry's failure to discover an effective methodology (at least as of January 2003) is that we keep inventing disciplines that we cannot sustain. So perhaps the GreatFailureOfXp is that it appears that it is, in practice, not sustainable. Let offer a contrast to, for example, the ScientificMethod -- which apparently is sustainable, which seems to address an interesting (even if not all-inclusive) set of problems, and which does not need to be "completely implemented" in order to yield successful results. Our culture is filled with artifacts, some "better" than others, that have resulted from unsuccessful attempts to apply the ScientificMethod. The ScientificMethod, as a methodology, persists not only because it works when completely implemented, but also because it is helpful even when discipline fails. It appears that the character of Xp is different from this -- TomStambaugh
And the "Great Failure of XP" is? Some concrete examples, theories, or explanations would provide some grounds for discussion. [I would suggest that all of the preceding text be deleted and this page be restarted from a clean slate.]
Or, since this is more of a discussion of CritiqueOfXpxec, move it all to CritiqueOfXpxecDiscussion?...unless Marty, Sunir, or another would be willing to summarize the Great Failure of XP here. -- BrentNewhall
Yeah, this page is certainly a RefactoringCandidate
. My primary point is twofold; that XP, like any high-discipline methodology, has to be used in a high-discipline envionment or it falls victim to slovenliness; and that XP can not
be applied to certain industries like the embedded systems stuff I do most commonly. Perhaps some WikiMaster
can help to clean this page up. If not I'll do it myself after a while. -- MartySchrader
is that it appears to be, in practice, not sustainable in commercially viable enterprises. -- TomStambaugh
I can state from experience that a partial implementation of XP is not a failure... though it isn't an ideal situation either. Every unit test we write reduces the amount of debugging we have to do. Before adoption "partial XP" we had lots of debugging. After adopting "partial XP" we had less debugging, even though we don't have 100% of code unit-tested. We go faster when we pair program, and we go slower when we don't pair program. Management support helps in the management practices -- iteration length, story-writing and scheduling, etc., but we can still do those practices less well without management support. We still ship software regularly with acceptible quality, and thus we are "successful".