The feedback loops were too long.

Real-world waterfall always contained the idea of feedback from later steps changing the results of earlier steps. (Not having this means you have to be essentially perfect in your earlier steps to avoid having garbage input to your later steps. That can't be done. What's more, circumstances change during the life of the project, and if you don't respond to that, you're programming for the world as it existed six months or two years ago, and that is a recipe for failure.) This feedback to earlier layers was considered entropy, and the task was to manage it, to keep it from running out of control. The result was that you could be implementing something a year after the requirements were done, and six months after the design was done, and if you saw any problems, you were supposed to not revise the design (still less the requirements) unless you really had to.

In contrast, agile wants to have those times as short as possible, and to feed what you discover during implementation back into the design (and even requirements), in order to get them to better conform to reality.

Real agile is all about keeping the feedback loops tight. Waterfall was all about wholly completing phases, in order. This lead to waterfall being rather unresponsive to new information or external changes. (To see how demoralizing this can be, imagine working to implement something, where for the last three months you know it's the wrong thing.)

The delivery aspects of waterfall usually means it is a rigid and structured organization with people in rigid and structured roles that have defined responsibilities.

This can drive bad behavior, pitting teams like requirements analysis, design, development and test against each other since they sometimes have competing interests.

In a larger organization, competing interests emerge since these teams are often managed by separate people who manage and measure their people with objectives that are for the role. People who write requirements get focused on common ways to document requirements, templates, etc.

A rigid organization using waterfall tends to have very structured, approval oriented deployment processes which leads to things like only having project launches 3 times per year. A weekend launch starting with a backup of the system on Friday in case they need to restore Sunday night if the long sequence of 300 deploy steps is somehow botched.

I went from organizations like above into one that uses a Continuous Delivery model. This means we deploy every day, multiple times a day if needed - to production. Small changes that are testable with builds being tested continuously, operations of the environment heavily monitored and developers own their changes into production.

I think the main issue with waterfall development was the corner cutting at every step. Because software is not as hard to modify as hardware projects, it would be faster to do a shitty waterfall plan where the requirements would not be completely understood, and the implementation design lacked some major use cases, and implementation would miss other things like error handling, and the final product would be crap needing fixing.

The issue is that it would be cheaper to do it that way, because trying to get all requirements right and implementation right before doing was really expensive and still incorrect in he end. You'd always end with bugs or missing features...

Waterfall means at least two things. I'll assume for my answer that it means only one of two things which I'll discuss.

All development process models assume the following tasks:

  Requirements collection
  Analysis
  Design
  Development
  Testing
  Deployment

After the first iteration, you move to maintenance. The only difference for maintenance is that "requirements collection" is more focused on collecting problem reports and change requests. Most of the requirements are already established.

Waterfall:

One meaning, the original and literally the worst thing ever, is that each of those activities is completed essentially in whole before the next and without feedback from the successor activities. The only feedback is when you get to maintenance and collect PRs/CRs from the customer and start the whole thing again.

The practical versions introduce some feedback loops but typically only up one level at a time. So test obviously feeds back to development which feeds back to design, etc. The problem here is that this is still a very slow process.

The problem with waterfall (the practiced version) beyond the poor feedback loops is also the time delays involved. Your analysis board which decides which PRs/CRs to work on may only meet every 6 months. So the average PR will sit in a queue for 3 months before it's even considered for work. And the results of the analysis board may not make it to the developers for another 3 months so the average PR won't be worked on for 6 months. And because many PRs are collected and started at once, integration testing typically waits until they're all done. So it could be a year or two before a full integrated build is produced and an issue discovered which forces you back to the design phase to fix a critical issue.

And, while the developers and testers are doing their thing another analysis board meeting happens and introduces more PRs. By the time a product gets released it's often 1-3 years behind what the customer actually wants or needs.

Waterfall only works if you have trivial projects, or projects with very clearly defined scopes and requirements that are being planned on the order of years or even decades anyways. This isn't most software.

Let's say waterfall == large batch size. The actual problem is the large batch size.

The larger the batch size, the less time you spend designing, coding and delivering, and the more time you spend (mis)managing the batch - what goes in it, changing what goes in it, planning what goes in it, explaining what will go in it, explaining why half of it didn't go in it.

All of this invites a certain type of personality who is not incentivized to deliver but to talk about delivering. That is when the horror stories start.