I would at this point argue agile is the new waterfall. It's so common that the phrase "we're doing agile" vaguely hints at a few practices that may or may not be relevant to the discussion. Mostly it means "we have standups" and "we promoted some juniors to scrum master and pm roles".

It's mostly devolved to ritualistic bullshit performed dogmatically by corporate idiots. Every shitty third rate software sweat shop does agile/scrum these days. You need to look pretty hard to find companies that are not very eagerly proclaiming they do agile.It means absolutely nothing until you qualify what that actually means for you.

Those claiming they are doing it "right" or by the book are the worst because that means they read some stuff without grasping the meaning of what they read. Basically, the agile manifesto signers have come out arguing against that. That was the whole point of that manifesto. They basically provided us with tools, practices, and ways of working that we're supposed to adapt to our context as needed. They don't say: do this dogmatically and follow my instructions by the letter. They actually say don't do that but if you are getting started you might as well do this and then adapt as needed.

That's sort of the same thing that went wrong with waterfall. The article points out a few historical twists to historical context of that. I read the paper by Royce long time ago and found it to be quite modern and insightful. It doesn't mention waterfalls at all (as the article points out). It also points out that, waterfall as we know and love it, basically was institutionalized bureaucratic government organizations using it to sugar coat heavy processes that they came up with that got subsequently adopted as "the way to do things" by equally bureaucratic large software houses they worked with. It got a bad reputation for said corporations making obscene amounts of money with obscenely bad software delivered late and never on budget.

This pattern is something that is a constant and was referred to as the software crisis in the 1960s already and lead to Margaret Hamilton along with other famous pioneers in computing coining the notion of software engineering in the 1970s. She was of course working on the lunar program at Nasa (speaking of bureaucratic organizations). The software crisis is alive and kicking. Many scrum/agile organizations continue to peddle atrociously bad software developed. That doesn't mean that nothing has changed but you should beware of anyone claiming to know the one and only way to do stuff.

There's a lot of common sense that inspired agile and waterfall. I'd argue the modern take on this is to replace manual processes with automation to facilitate rapid flow of changes from inception to production. Another trend is to decouple decision points to facilitate asynchronous processes and communication. For example, you don't bundle features into releases. Instead you ship pull requests straight to CI and CD pipelines. That means that there are no central planning bottlenecks for delivering new features and they can be developed on their own schedules. This happens continually. Most big brand websites you use, update many times per day. Iterations and sprints are kind of obsolete as a way of orchestrating release schedules.

That practice is now creeping into the enterprise. If you are doing scrum and being told not to do this, that's something that you need to challenge.