If you think I'm wrong, prove it. And I mean PROVE AGILE WORKS, WITH EVIDENCE or shut up. Extraordinary claims require extraordinary evidence. I didn't come into your life and tell you how to suck eggs, but if you're going to come into mine and do that, you'd better have data to back you up.
The burden of proof isn't on me. It's on the Agile crowd. What evidence have you got?
Off the top of my head though, how about having agile and non-agile teams complete a project from the same designs, with amends and feature requests introduced at scheduled intervals. Study the results. I'm sure someone with a background in constructing these kinds of studies could work out the kinks and make sure it's a fair comparison.
It's unfeasible because you'd need a large sample and those kind of people aren't likely to take two months out of their life to work for free on a science project. And I guess that's why Agile goes largely unchallenged. No one can afford to do the science to prove wether or not it works.
And the ones with evidence and experience proving that it doesn't work are people like me who have to put up with being told I'm wrong, and I'm unlucky and it's all somehow my fault that I can't reproduce the results. It's like everyone is claiming they've cracked cold fusion, and it's my fault, not theirs, that I can't detect the neutrinos.
And the ones with evidence and experience proving that it doesn't work are people like me who have to put up with being told I'm wrong,
Well - what's your evidence then? I am genuinely interested.
Because - anecdotally - the most effective teams I've worked on or observed over the last 20 odd years have been the ones that are doing more "agile" things.
There's a fair amount of survey research (e.g. http://www.agilemodeling.com/essays/proof.htm) that seems to show agile teams are more effective. I've seen very little research that implies otherwise.
So I'm obviously going to go with my experiences on what works and the research that I've seen. You are, of course, free to do stuff based on your experiences. But I don't see why your anecdotes beat mine ;-)
I don't have any evidence. And neither does the Agile crowd. What they have is anecdotes. So if their anecdotes are valid proof for agile, my anecdotes should be valid proof against agile.
As for the evidence that people are publishing (such as the stuff linked to in that proof.html link), that's no evidence at all. It's cherry picking. It's saying, "Pair programming worked well in this controlled study, and XP worked well in this controlled study, so putting the two together is guaranteed to work together flawlessly and there can be no unintended consequences". The evidence ignores more than it acknowledges.
In addition, when a successful project launches that used Agile, it is used as evidence that Agile works. But when a project that used Agile turns out to be an unmitigated disaster (Such as Accenture's NHS IT project to pick one cataclysmic example) the Agile cheerleaders are no where to be seen.
When Agile goes wrong, it goes spectacularly wrong. Take that NHS example I mentioned. 10 years in the making, £5bn of tax payers money, it's still not finished and Accenture plain up and walked away from it. Find me an anecdote better than that in support of Agile.
But of course you wont. You will say "well they were doing Agile wrong" and you will have no evidence for that.
But of course you wont. You will say "well they were doing Agile wrong" and you will have no evidence for that.
Curiously enough - I won't say that. I will point out that Agile is only just a bit over ten years old now, so a ten year £5billion agile project sounds... odd... to me. It certainly sounds atypical for projects in general.
But yes - agile projects fail. There is no system that will cause all projects to succeed. There is - as they say - no silver bullet. No argument from me there at all.
Let's forget the "agile" word for a bit.
How do I go about getting better at building software and building teams that make software?
Personally, I do things like:
* I look at research
* I look at successful teams I've worked on / observed and try out some of the things they do
* I look at failed teams and try and avoid doing some of the things they do
* I look at the stuff I try and see whether it works or not.
* I measure stuff - tweak what works, avoid what fails
* Repeat.
That kind of process, for me, has led me to a chunk of techniques that broadly sit under the lean/agile label. I'm not going off and going "yay agile". When I first encountered XP I was hugely sceptical - I really couldn't see how it could work effectively at all. But I tried some bits of it, and observed some other folk playing with other bits of it, and saw that it seemed to improve things, so tried some other stuff... and so on.
I'm not trying to say agile solves all problems. It's not a silver bullet. It's really freaking hard to impossible to use it in some contexts. But in the last ten years my personal experience it's helped me and my teams get better and building stuff. The experiences of a stack of people I've worked with who I respect, and the experiences of a stack of other people I've talked to and listened to and visited have been similar.
I'd like to think that we're not all complete idiots ;-)
So - if stuff fails I love to poke at it. When agile projects and when non-agile projects fail I poke and try and learn from it. Generally - I think I've got better at delivering stuff that makes my clients happy during my career. A stack of the skills that have helped me do that in the last ten years seem to have come from the agile community. Take from that what you will.
What kind of evidence would count - for you?