Will my personal anecdotal experience qualify as proof? What if enough people comment on this article with their anecdotal data?

I’ve seen over a million dollar software development budgets spent in waterfall projects (plural) for enterprise software that were never deployed because they got so far off track with the (admittedly moving targets) of customer requirements. I was a dev lead on one of those projects (my first dev lead role).

I’ve also lead a team through a very successful iterative project – releasing every three weeks, using continuous integration – with a single exception, every nightly build of the trunk was bug free and we leveraged that twice to deliver unscheduled releases.

I’ve been on projects that rolled out initial, valuable functionality that immediately began generating a return for the customer. Those projects also gained momentum through delivery that helped them stay funded and visible throughout their development cycles.

I’ve helped clients with “broken” processes reduce maintenance costs and simultaneously improve quality and reduce feature-release cycle times by introducing continuous integration, automated build and test procedures and habitual refactoring into their dev cycle.

The most successful projects I’ve personally worked on, lead, or been aware of have universally applied elements of agile processes. The most spectacular failures have all been waterfall processes with manual build cycles and quality procedures that lacked rigor.

I don’t believe you can isolate enough variables to create “scientific proof” that it works. Even if you have the same team implement the same software with multiple methods, those people will learn something the first time, making the second attempt better than the first. And if you have teams simultaneously create software to address identical needs you can not factor out the team-member skills as a variable.

Other folks want to chime in?