Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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

    • by ziggy (25) on 2006.10.07 21:27 (#50877) Journal

      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.