Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity. Waterfall doesn't mean not to iterate. It also doesn't mean…
Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop.
But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself.
(Sadly I’ve lost the link to the original paper, but if I find it I’ll update my comment)
> Besides, waterfall is just the straw man of scrum zealots.
The irony is that scrum itself is often just a wrapper for a waterfall process with all the problems it comes with. So many corporate implementations of scrum are AINO - agile in name only. Management that doesn’t understand the complexity of software is doomed to oversimplify it.
That said, if you are working iteratively - one feature at a time, with feedback - then whatever you call it, that’s not waterfall.