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//;
Success Criteria (Score:1)
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
Re: (Score:2)
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
problems with wife (Score:1)
Is this the guy who tried to eliminate perl at Amazon because he considered Larry Wall to be insane?
The revelation that Agile Manifesto is really Egomania Itself could have been funny, if he hadn't told us that sick anagrams of his name had upset his dead brother.
I am sympathetic to his idea of experimenting. I never know if my own programs are going to work until they're finished.
There i
Re: (Score:1)
Well, Perl is ugly.