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.
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.