> with milestones where each step of the waterfall would be delivered and checked by the customer
I think this is one of the things that don't explicitly follow the waterfall diagram as presented and criticized though. You're delivering smaller units of work here and I presume incorporating their feed back at least to the extent of if it is functionally meeting the specified requirements which is kind of agile-y.
The main difference between the two at that point seems to come down mostly to the willingness to revisit the requirements which even when my employer was more waterfall we would try to incorporate changes if the customer came back and said what we were doing wasn't going to work at all or they needed changes.
Nope, in waterfall, "deliverables" might mean things like "UI design" (as a slide deck) or "database schemas" (on paper, without data) or "this microservice" (in isolation, and which you cannot run because dependencies and consumers are not implemented yet)
If you are producing anything a customer might actually before the very end of the project, it's not waterfall.
That's what the article is saying in part. Very few people showed or tested absolutely nothing before the very end of the project so if that's a requirement to be 'waterfall' it was a strawman that's easy to argue against.
I think this is one of the things that don't explicitly follow the waterfall diagram as presented and criticized though. You're delivering smaller units of work here and I presume incorporating their feed back at least to the extent of if it is functionally meeting the specified requirements which is kind of agile-y.
The main difference between the two at that point seems to come down mostly to the willingness to revisit the requirements which even when my employer was more waterfall we would try to incorporate changes if the customer came back and said what we were doing wasn't going to work at all or they needed changes.