I would also point out that a lot of organizations think scrum ceremonies and sprint satisfy the requirement for ticking the agile checkbox, but in reality, practice waterfall.

Most companies I've seen recently, including a lot of startups, are operating in a waterfall that they then window-dress every 2 weeks in the form of SCRUM-ish rituals and ceremonies as if it's agile because it has iterations and story points or whatever.

Behind the scenes the PMs are making Gantt charts and deciding what's in and what's out and who is going to do it, without the team having any input or really getting to cost it out.

XP and agile generally was supposed to about shortening the communication and iteration gap between customer and maker. I almost never really see that.

I would guess "big conservative companies" with waterfall are by far the overwhelming number of programmers, even if agile startups may (may) win be market valuation.

Then there's the definition - like, is SAFE really agile plus so many other hybrid approaches that have veneer of agile as long as we get all requirements up front and have detailed plan.

If waterfall didn’t exist then there wouldn’t be release dates and software being pushed out before being done. Waterfall is there; it’s just at the top of the project.

The ol all requirements up front -> design -> implement that people classically associate with waterfall came from an infographic on how not to do waterfall.

Actual waterfall looks very much like actual agile, in that it is designed around iteration loops. The primary difference is that waterfall prescribed steps in the iteration process, and agile is just a set of principles in a manifesto.

Edit: reference: https://beza1e1.tuxen.de/waterfall.html

TLDR: the original impetus for waterfall is basically what we call agile today.

Someone copy-pasted a random chart from a paper (one the paper specifically said was too problematic) into a DOD process spec, that turned into a standard because the DOD loves to standardize everything, and big companies all adopted the fundamentally flawed approach and called it waterfall.

Apple famously uses waterfall.

Waterfall is suboptimal because it's optimistic and lacks feedback loops. Waterfall as codified was not the improved process Royce described, but the flawed process early in his paper.

It's optimistic because it carries an assumption that you can delineate your development into clear phases with a distinct start and finish. That doesn't work on large projects. You don't spend years designing your new system and then years building it and then years testing it. You commingle each of those, and once you do that, you're not doing Waterfall. You're doing something better, you're using your brain.

Iterative & Incremental, Spiral development, or most ideas out of the Agile movement are better. They incorporate feedback into the project and don't have strongly delineated phases. They don't make 10 year project commitments before they've even written a single requirement. Because these are methods that are realistic.

We didn't get to the moon by Waterfall. The Wright brothers didn't succeed in flight with Waterfall. Linux wasn't developed with Waterfall. Waterfall is a failure for large scale systems.

AI loves waterfall because every time you insert yourself in the agentic coding loop you reduce the velocity of the system, and if the system blocks on your input the reduction can be pretty epic. Beyond that, AI has myopia, and if you tell it to implement something without a larger framework it understands how to slot it into, it'll put it somewhere that makes no sense, duplicate code, make incompatible interfaces, etc. It's much more efficient to just have the system outlined clearly from the get-go, and this also helps because you can generate E2E tests for validation up front to ensure the features really are valid and working.