> The whole horrible waterfall process was an urban legend

Bullshit.

Source: I lived through it in the early and mid 1990s.

I'm living through it RIGHT NOW. I'll give you one guess who pushed it on us. And I'll even give you a hint: it almost rhymes with "rubbermint".

It happens outside government too. It happens anytime your higher-level boss tells you: "Yes, I'm on board! You're right, a system like that would help us tremendously in several ways! Please estimate the costs for it so I can get us the money in our budget meeting next month." Happens all the time in enterprise businesses and the newer methodologies are extremely difficult to use in this sort of situation. In this case, I need some specs up front, create dev estimates, all to ultimately deliver a rough dollar amount or sometimes a "not to exceed" number for my boss...

Waterfall is only mostly dead. I'm told that the reason why the public sector prefers price-and-scope-up-front is that the alternative of "we'll keep delivering things as long as you keep paying us" sounds to them far too much like ways that they have been ripped off badly in the past when buying tanks, bridges, etc.

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.

That is absolutely the reason. On top of that, the only reason they want to use iterations (along with the dreaded inchstone) is so they can use Microsoft Project as a progress bar. If you try to change your iteration deliverables (that were set three years ago) because of actual project issues, you get a ration of shit from the government and their advisors.

Bullshit x 2.

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.

Don't know about the formalization by Royce, but I've witnessed and suffered waterfall in practice - let's call it ad-hoc waterfall if you will - and it was no urban legend.

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.

I'll just leave this here.

https://plus.google.com/+LaurentBossavit/posts/VBJTGru3PeW

Or this.

http://leanpub.com/leprechauns

No one ever read Royce's paper, they just accepted the PMI/PMBOK interpretation of it as sacrosanct.

Which was a gross misinterpretation to this day. We still have naive PMPs running $100 million IT projects in the faux-Waterall style.

yeah... i never heard of waterfall until after experiencing a naive use of scrum and having it referred to as 'the alternative'.

Good for you. Some of us old-timers have lived through pure waterfall, waterfall-inspired, and guilt and shame for not doing waterfall right.

The guilt and shame is so spot on. Living though such projects illustrated so well the "the beatings will continue until morale improves" project management school of thoughts.

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.

I was part of a development organization that, driven by guilt and shame, tried to mature and improve their "ad-hoc" processes by fully embracing by-the-book waterfall.

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.

> The guilt and shame is so spot on

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!

oh, don't get me wrong i've worked in that environment, but its just a natural naive way of doing things - dignifying it with a name seems to be something that happened later

Some companies did use it. But even at the time (before Beck's book), it was known in programming literature to be a dumb idea. XP didn't introduce the idea that Waterfall was nonsense, it was just the catylist for it's removal.