The Royce paper is actually still worth reading. It's well written and if you can step over the 50+ years of history since then also still somewhat informative. And of course the word waterfall doesn't actually appear in it. That word was slapped on it by others afterwards. And of course Royce vaguely suggests that going through the steps more than once might be helpful. What we now call iterating.
The key concept for what we now call agile (which mostly boils down to variations of scrum these days) actually has roots dating back about half a century. People were suggestion spiral development at some point (converging on some final thing) as early as the eighties. There was the whole 4+1 model which got caught up in the whole UML movement and it's associated process.
The key innovation that extreme programming (one of original agile methodologies) brought was that increasing the iteration frequency and giving up on the notion that you can do a lot of requirements and design up front. Things change. Every iteration. So having a lot of requirements and design documentation to update every cycle is counter productive. Dropping that was considered extreme. But then people realized that that worked just fine and that these designs were kind of low value artifacts to begin with. Not really worth the hassle.
With Spiral, the iterations explicitly involve the customer. This is important.
With Waterfall, there is an upfront spec, but implementing the whole thing without consultation with the customer can be a bad experience.
With Agile, maybe there's a lot of internal correction. But the key thing is to involve the customer in integration testing. Unless both sides are very experienced, surprises due to miscommunication are the rule.
It's mainly iteration length that has shortened. Royce was saying do it twice (including requirements engineering, which presumably would involve some kind of feedback). Spiral development increased that to doing it multiple times. Rational unified suggested a quarterly pace. Most agile methodologies work with sprints of a few weeks.
And lately, continuous deployment and Kanban like methods remove iterations completely and release continuously. Ship when ready and develop asynchronously. You can still have planning cycles with this of course but they are decoupled from release cycles.
The Linux kernel is a good example where you either make the merge window or wait for the next one. Large companies like Meta are also know to work with scheduled releases that are independent from planning cycles (e.g. weekly) of teams.
The key concept for what we now call agile (which mostly boils down to variations of scrum these days) actually has roots dating back about half a century. People were suggestion spiral development at some point (converging on some final thing) as early as the eighties. There was the whole 4+1 model which got caught up in the whole UML movement and it's associated process.
The key innovation that extreme programming (one of original agile methodologies) brought was that increasing the iteration frequency and giving up on the notion that you can do a lot of requirements and design up front. Things change. Every iteration. So having a lot of requirements and design documentation to update every cycle is counter productive. Dropping that was considered extreme. But then people realized that that worked just fine and that these designs were kind of low value artifacts to begin with. Not really worth the hassle.