> the clean cut from waterfall
...was in fact a strawman. The whole horrible waterfall process was an urban legend: http://postagilist.wordpress.com/2012/06/13/the-perennial-wa...
...was in fact a strawman. The whole horrible waterfall process was an urban legend: http://postagilist.wordpress.com/2012/06/13/the-perennial-wa...
Bullshit.
Source: I lived through it in the early and mid 1990s.
However there is hope. www.gov.uk is a notable recent success story. https://www.gov.uk/service-manual/agile
The difference is that in the early 1990s, most of us thought that larger software projects were just like that. We didn't know any better.
Not only are there projects where waterfall methodologies were applied, but they are sometimes (gasp!) appropriate.
In the majority of cases, iterative development of some sort is necessary, because the requirements keep changing. Waterfall simply doesn't allow for changing requirements, so it's hopeless in those cases.
But where requirements are stable, waterfall is a reasonable approach. Remember, it had its origins in the big iron days, when vast project teams analysed and replaced existing manual systems. For those projects, waterfall worked.
If you're writing the code for a space probe, or a missile, there's a limited opportunity to iterate once the item is deployed... requirements are stable, waterfall can be a rational choice.
And on moonless nights I still wake up screaming remembering a RUP project I was involved in around 2000.
"No true scotsman" and all, I know.
https://plus.google.com/+LaurentBossavit/posts/VBJTGru3PeW
Or this.
Which was a gross misinterpretation to this day. We still have naive PMPs running $100 million IT projects in the faux-Waterall style.
This school has its agile proponents too, though. But compared to the common practices of the penultimate decade, XP and Agile at least acknowledged that failure was the default mode of software development projects, and made contingency plans for it.
Absolutely. If the waterfall isn't working, you need to waterfall harder. Because more time spent up front writing paper architectures and guesswork requirements is what's needed!
To me it felt like they were saying, "You know all the things you did to make your last project a huge success: the short iterations, tight feedback loops, early and frequent customer involvement, designing your systems to accommodate change? Yeah, don't ever do any of that again."
So I left, and found that dogmatic by-the-book scrum shops can also be horrible places to work. Live and learn.