On the other hand, in my 50 years or so in this business, working with every size of company, I have never actually seen "waterfall" being done in practice. I'm sure it may have happened -- as you report -- but I don't think it was ever common.
In my ~20 years of mostly startups and small businesses I have seen waterfall creep in at almost every company. You start by being small-a agile because there is no process. Then something happens – a few big fires ship, or someone misses a requirement, or an exec gets grumpy about feeling a loss of control, or internal users start treating it as just-a-job and want official training for every little thing, or you get engineers who just want to code – and your small-a agile process turns into waterfall.
Ah but we’re a startup, we can’t do waterfall! So you do a series of tiny waterfalls and call them Agile. Everything takes eons of planning, the management class feels super busy, the engineers become disempowered and widget factory like, and all the plans are wrong by the time you implement.
You start getting lots of “we’ll figure out the details then engineers just need to implement, it’ll be easier that way”. It is not easier that way.
There has to be some process, for tracking and communication. We should just have an industry-wide standard that management gets to impose a 5% process tax on hours spent and no more. And we should explicitly recognize that test, design, communication, teaching, engaging with the customer, triage and debugging are how software gets built. There is no magic process bullet. Its a wasteful story invented by management who existentially cannot admit that they have no control over the situation.
Remember that this is largely about consultants selling advice to executives. This is not about getting stuff done.
BUT software is also a young industry. We just don’t know yet the right way to do it so we discuss and share what’s worked for us. Just like it took a while to find the right manufacturing processes in other industries.
Sure, you do requirements elicitation, review and documentation, and then architectural design, followed by detailed design & coding, etc. But it's never a linear process end-to-end. There's always feedback. There's always something you didn't account for showing up and requiring a change to an earlier part of the process.
Waterfall can, and does work, but only on fairly small projects that can be completely defined correctly the first time around. And like everything else, it's easier if you've done that kind of project before.
It is absolutely the case though that many projects were driven with management methodologies way, way too far to the Waterfall side, and that managers would attack developers for essentially failing the process if anybody ever had to incorporate feedback or backtrack or do anything other than 100% rigidly and correctly follow the previous plan.
I don't consider it a "strawman" so much as a "simplification". Nobody could ever truly do waterfall for extended periods of time but there were plenty of people who acted and managed on the idea that the ideal is very, very close to it and to the extent deviations were necessary they are all automatically failures. To the extent that one is trying to discuss management methodologies across an entire industry, if not arguably across multiple industries simultaneously, waterfall is not an unreasonable approximation.
And personally I think in the occasional interminable "oh wouldn't it be wonderful if programmers were real engineers like architects" threads, where people fail to understand those processes used by other engineering disciplines are contingent based on the nature of their work rather than abstract Platonic ideals all should strive for, and those other disciplines would love to work with continuous integration servers and automated testing and strongly-typed components, there are a lot of developers that believe even today that if we just tried hard enough, waterfall could not only work but be the optimal design methodology, and it is we who are failing waterfall rather than the other way around.
You captured so much in this one sentence, especially the end, about how waterfall failed the developer, rather than the developer having failed waterfall.
This script-flip works on many other systematized orthodoxies, I suspect.
In that, he first introduces what has come to be known as Waterfall. While he considered it to be fundamentally sound, he posits that it carries significant risk and then goes on to tell what needs to be added to diminish the risk. Those additions are what oft get called Agile (although not in the Manifesto sense).
You have a point that "simplification" is more in line with the device he was trying to use, but with the intent of leading you into understanding the more complex aspects of his idea. Kind of like that owl drawing meme where you start with two circles and then draw the rest of the owl. There is only one idea present. In other words, "Waterfall" and "Agile" are the exact same thing, just at different stages of communication.
Where others have tried to invent "Waterfall" as it own distinct thing to contrast with "Agile", it would be fair to characterize that as a strawman. If anything all projects are "Agile" at their core, with varying degrees of deviation happening in a multi-dimensional space.
If the software industry had the equivalent of "general contractors" who pour the concrete, wire the rebar, dig and fill the holes, install the electrical and duct, laid the bricks, all to within the tolerances specified; AND had architects who knew both the tools available and the domain inside and out, a model mirroring the real estate industry MIGHT BE doable. But there are a lot of differences beyond just the "engineering" aspects (and often times, the head engineer on a project is not the architect).
I consider it a straw man because, as the agile crowd describes it, there appears to be no such thing as "waterfall". Perhaps that is the result of comical oversimplification rather than a conscious attempt at deception (I believe this is the case), but it still results in standing up a straw man so it can be knocked down.
I just haven't seen that happen. I'm sure there are exceptions where it has, but I think those have always been rare.