> In reality there is no competent team, using waterfall or otherwise, that relies perfect estimates and I wouldn't insult anyone by claiming they're doing so.
The waterfall is process where you start by collecting requirements, make estimation and sign contract with set deadline. The rest is development in one go, then testing and then you give result to customer. So yes, it relies on precise estimations. Whatever else you have in mind is not waterfall process. Waterfall does not prescribe how exactly you make estimation nor how do you communicate inside the team.
It has disadvantages which is why no one was using it for decades. Except as straw process to blame when other processes fail or dont prevent dysfunctions. So, management tries to implement scrum, it fails or turns into hell. Then next guy will try to implement Scrum or whatever, claiming he is bringing agile to save us from waterfall. But that is just a way to avoid saying that it was scrum that failed and repeating exact same cycle.
There is a difference between a perfect estimate and what you're describing.
Again, literally no competent stakeholder anywhere is expecting a perfect estimate.
Both agile and waterfall both aim for precise estimates.
With agile you're still aiming to have roughly correct story points, or having roughly enough work for your sprint. But you're moving the yardstick on how often you estimate and how you handle missing those estimates.
All of which is why again, I don't see the point in being so rigid in where one ends and the other begins. Waterfall has gone from a punching bag to a real process people follow by adjustment. People seem to miss that while the "OG" waterfall diagram was supposed to be flawed, even in the same document practical improvements were introduced.
> Again, literally no competent stakeholder anywhere is expecting a perfect estimate.
Incompetent stakeholders are real world phenomenon. In this sense, even stakeholders that are otherwise smart people and competent in other areas often fails in exact this way. Real world companies pay fines for being late. Real world customers without contractual guarantees end up paying more then project is worth too.
> Waterfall has gone from a punching bag to a real process people follow by adjustment.
This is the thing I disagree with strongly. Waterfall is punching bag and is not used in practice at all. It was past being used when I was young. Waterfall was also far from the only process that existed before agile came.
Iterative development process existed long before agile came to be. Agile means nothing and everything these days. Waterfall however is canvas where people project their grievances with other processes. That is why it is undefinable in these threads - it is either about communication, or people being treated bad, or about iteration or host of other practices that companies combine together.
The waterfall is process where you start by collecting requirements, make estimation and sign contract with set deadline. The rest is development in one go, then testing and then you give result to customer. So yes, it relies on precise estimations. Whatever else you have in mind is not waterfall process. Waterfall does not prescribe how exactly you make estimation nor how do you communicate inside the team.
It has disadvantages which is why no one was using it for decades. Except as straw process to blame when other processes fail or dont prevent dysfunctions. So, management tries to implement scrum, it fails or turns into hell. Then next guy will try to implement Scrum or whatever, claiming he is bringing agile to save us from waterfall. But that is just a way to avoid saying that it was scrum that failed and repeating exact same cycle.