The problem is even more fundamental than that. The point of these extra steps in Royce's eyes is to ensure the developers deliver exactly what the customer ordered. Page 335 - "Step 5: Involve the Customer" - Royce wants to push design risk to the customer by committing the customer to sign off specific requirements along the way.

This leaves the project open to delivering the wrong thing. It doesn't matter that the customer specified the wrong thing and everyone else implemented exactly what was asked for, because in the end you all failed to meet the original goal - to solve a specific business problem through the introduction of a software system.

Agile recognises that no one knows exactly what's needed ahead of time - Royce kind of recognises this but only for the software developers with his idea to build then throw away the first system then deliver the second ground up re-write to the customer.

Agile says we'll all learn together as we build, we'll minimise risk at every step by only taking such small steps each iteration that we're completely happy to throw the iteration in the bin if we got it wrong.

Agile is just 20-30 small waterfalls instead of big one. How small a waterfall needs to be to fail?

Honest opinion: Its not a matter of size. Its a matter of completeness. Agile or waterfall processes fail if you omit the Qualification step, or if you don't ensure that the analysis produces actionable requirements, or clearly formulated specifications that lead to requirements, user/technical/or otherwise.

The whole point of agile is qualification through working software and getting feedback. There is no amount of analysis or requirements gathering that can compete with delivering an understanding of the requirements to serve as a model for how to move forward.

That Qualification step was the challenge I had when working on scrum projects in the past. I might finish implementing a feature in the current sprint #1, but QA won't get to start testing until sprint #2. When QA inevitably finds bugs, when do I fix the bugs? Should I have reserved an unknown amount time in sprint #2 for bug fixing? Or should I schedule time in sprint #3 to fix those bugs? If so, then the separate implementation/QA/bug fixing stages are each adding extra latency.