From this followup to Good Agile, Bad Agile:
If you want real supporting evidence, you should construct the scientific kind, using experiments. Yes, I'm afraid that means looking at the failures too. Ouch! So bad for marketing. Whenever you hear Agile people asking around for "success stories", remind them politely that only looking at the positives is pseudoscience.
(emphasis added)
My only response: s/Agile//;
It also helps to have a rigorous definition of "success" too. I've seen projects that ended because they were no longer providing value to the customer. I consider it a sign of success if, due to agile development, the customer and the developers discover this as early as possible--even several months into the project--rather than much later, towards the originally scheduled delivery date.
I must admit that I'm very curious who these Big-A Agile hucksters are. Most of the agile and XP people I know are a lot smarter than you might think from these characterizations.
Re:Success Criteria
ziggy on 2006-10-08T02:27:48
It also helps to have a rigorous definition of "success" too.
Yep. Moving the goalposts doesn't help anyone.
I've seen waterfall projects appear fail after 3 months, because someone was a little too sensitive to the amount of big up front design, a looming deadline, and no code to show for it. It's hard to tell, given a full 12 months, whether BDUF and Agile methods can both deliver something of equivalent value. My superstitious guess is that BDUF is more risky because it tends towards diddling on creating frameworks. There's no guarantee that an Agile project won't devolve into a framework building exercise, nor that a focused team doing BDUF can avoid building unnecessary frameworks.
We can't do that experiment, because Heisenberg lives here. What is clear (and Steve makes this point) is that a given enough hard work, a talented team will deliver, regardless of methodology. But that's a fundamentally unsatisfying answer because it's a tautology, and leads to the conclusion that methodologies are pointless.
I think that the real answer here is that by default, all development teams are disorganized, undisciplined and ineffective. The only way to be effective is through some kind of organization and discipline. XP (in particular) helps because it offers underperforming teams a ready-to-use model for adding the missing pieces, not because it's a magical bag of pixie dust that makes projects work. But when you start applying agile methods poorly, the team returns to a chaotic and ineffective state.
I must admit that I'm very curious who these Big-A Agile hucksters are. Most of the agile and XP people I know are a lot smarter than you might think from these characterizations.
I have a sneaking suspicion that the hucksters are the kinds of people that preach the Agile religion without conviction or understanding. That is, the kind of people that latch onto the latest fad, lack clue, and are instantly ignored by anyone competant. In that respect, it's a little unfair to pick on agile methodologies as a proxy for picking on hucksters, simply because the agile tent is just where they happen to be this year.
Re:problems with wife
Aristotle on 2006-10-09T15:01:59
Well, Perl is ugly.
