Xp As Trouble Detector

Who hasn't heard that phrase yet? I heard it often enough and I found that whatever came after the dots was a reliable indicator of that projects major troubles.

"...we cannot test."

Don't laugh! I really heard that. Of course, they meant repeatable, automated tests that were quite hard to apply to their old legacy system that was to be decorated with a new GUI. You bet they were in trouble. Lack of knowledge about the old system turned out to almost kill the project.

"...this project is too big."

Size can be a major project risk for itself. See HundredPersonProject. To me, the statement sounds like: "We cannot split this project into teams with clear responsibilities and customer-supplier relationships." (Because if you can do so, you just have a set of small teams where each can do XP with their "customer") If you cannot split up like above, you're in trouble.

"...we have distributed teams."

How do they coordinate? Through specs? Through Test Cases? Do they integrate often or rarely? How do you plan and keep track of the progress? If the distribution of your team prevents you from following the principles of XP, that distribution may turn out to be a major risk.

"...our programmers wouldn't pair."

Hm, sounds like information hiding, fear of admitting mistakes, fear of talking to the teammates, fear of being supervised, fear of losing "private options" when coding. If your programmers are at all like that, you're in deep trouble.

"...our customer insists on a FixedPriceContract."

With the "consequences" that we must do BigDesignUpFront, can't adopt the PlanningGame, can't allow the developers direct access to the customer... Possibly an indicator that the old-fashioned methods are preferred for their undeniable advantage in allowing unpleasant realities to be hidden from the customer until it is much too late for anyone but the developers to bear the consequences.

"...our customers cannot come up with clear requirements."

This is a phrase that I heard quite often. With strong internal IT departments, they tend to force the customer to accept what the IT think they need (and in the end the customer will again get something that he considers bad). Another indicator for this is the phrase: "They don't know what they want. So we will tell them."

With strong (external?) customers you face the risk of ever-changing requirements and never-ending pressure on the development team. For the PlanningGame is one of the best practices of "Change-Management" that I've seen so far, I will always have a close look at this topic with projects doing it differently (even if they do it successfully - because then I can learn something :-).

"..." (unspoken)

Unspoken reasons for not doing XP always seem to be around. They leave so much room for speculation that they are the least useful ones for trouble detection. There may be a the habit of PlayingNotToLoose? in the project with the unspoken reason "If we do XP and the project fails, they will blame the process and the one who opted for it." (see YesMinisterCourageValue). But this speculation is not very useful and therefore I always ask for specific reasons.

to be continued... -- DierkKoenig

So if in trouble, don't do XP? Well, fair enough...

Well, that's one way to read it. But I think the point of this page is that many of the excuses people give for not doing XP are conditions that are dangers signs no matter what methodology people are using.

If the conditions are pre-extant, and unchangeable, the organization must adapt. If the problems are outside the scope of XP, as most of the above are (except for the testing one), then XP has nothing really interesting to say. For instance, XP says very little (if anything) about dealing with personality conflicts, so it doesn't apply to the situation when programmers won't pair due to animosity.

There's some circularity to this page; clearly, if everything were perfect, the project would succeed. So, who cares? How do we deal with the situation?

Also, you should be careful not to assume that if XP doesn't apply to the situation, the situation has failed. XP won't build UnearthlySoftware. "We cannot split this project into teams with clear responsibilities and vendor-supplier relationships," is a too simplistic dismissal. We all remember what happened when the MarsOrbiter crashed. But we also remember all those beautiful space successes. The space shuttle is the most complicated machine in the world, and it flies routinely.

Besides: There are no excuses, only problems and solutions. -- SunirShah?

Well, I think I should be clearer about my intention when starting this page.

I don't think that all projects should use XP, nor do I think that Non-XP projects are bad (only for that reason). The point is: I want to spot the major risks and troubles, e.g. when doing a project review. So I ask: "Have you considered XP?" And the answers will give me some hint on where to investigate further. See it as a consultant's trick.

Of course this tells something about XP as well. In a (true) XP project, you are very unlikely to find the above risks and troubles. You may find others, though... -- DierkKoenig

Thanks - good idea - here it is.

I got the impression that this page really means...

"I suggest that we do XP, but I'm told that we cannot because XXX."

And "XXX" is something that's going to kill the project, even if you don't use XP.

Like, if you can't test, then how does the authority who says you can't test intend to make the project successful, regardless of methodology, without testing???

And if your programmers have such serious interpersonal problems that they can't do PairProgramming, how are you going to apply any methodology that involves teamwork (like "teams")?

Good point. It's another view on this topic. I like the term "..but I'm told.." It expresses the uncertainty that is always around in these projects. They tend to speculate instead of doing ConcreteExperiments.

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006