It’s worth reading the original Waterfall paper. If you’ve only ever heard of it as the bogeyman, it might surprise you.

From your tone here, I think you are seeing “people over process” play out in your context. Celebrations? Talking? More talking? Time to do work? These all smell like a sensible organisation doing sensible things. Congratulations, you lucky &^%*&^%&^.

Some fools in industry, DOD in particular, looked at the pretty picture and codified it as an option among several for defined development processes. Then contractors and gov't managers picked it because it was straightforward (on paper) to plan and schedule, and it made it into practice. It's still used by DOD contractors today and it still fails. It's not a bogeyman, but Royce himself is not to blame, he was pointing out the stupidity and illiterate fools missed the point.

Agile development certainly has its place. Sadly, in most projects, it has become an excuse for clients who don't know what they want, combined with managers who are unwilling to force clarity in the requirements.

Thank you for summarising why I hate agile so concisely.

I don't hate agile itself, more the clueless people who think agile replaces requirement gathering and planning.

A core Agile tenant is responding to change rather than following a plan.

Your customer needs to know what they want. If they don't, then it is way too early to start development.

If they know only part of what they need, agile can let you start on that, while your requirements analyst (or equivalent) helps them work out the next part.

What shouldn't happen, is a lot of random sprints chasing ephemeral ideas. That's just a waste of everyone's time.

No, it shifts it, it does not replace it. Agile promotes the integration of what were, under classical Waterfall (courtesy of the DOD, in particular, codifying it) separate stages. Not separate in appearance, but actually separate. In classical Waterfall, following the DOD defined process which somehow escaped into the world, requirements, specification, development, and testing are separate stages possibly done by separate groups and executed in series. This is foolishness if it's a non-trivial project (on trivial projects you can use almost any process and succeed).

Agile is, in part, a counter to that foolishness: Those are not really separable things. You have to mix them for any non-trivial project. This means, if you're in a competent org, you do a mix of each of those activities (and others) throughout the development process, you don't remove them. At the start it's more requirements and specification heavy, with a bit of development and testing (prototypes, spikes in XP terms, and other things). As time goes on the process becomes more development and testing heavy as requirements and specification settle down, unless a real-world event makes the system obsolete before release. Then you figure out how to adapt to the changing circumstances which means revisiting requirements, specification, code, and test and figuring out what will surive, what won't, and how to make it work.

> A core Agile tenant is responding to change rather than following a plan.

That doesn't mean don't have a plan. It means don't be stupidly rigid, when the plan is overcome by events, respond to the events rather than stay committed to a now-wrong plan.

"That is, while there is value in the items on the right, we value the items on the left more."

You still absolutely get requirements and plan. You just do it in smaller, more granular pieces.

You can't anticipate everything like true waterfall expects, but you also can't just yolo into a sprint without some effort spent on specs / designs / architecture / etc.

Sounds like your client found a balanced approach.

I'm assuming that the requirements are documented and not altered every other day. Have to wonder whether your client is an engineering (not software) or related firm where they do detailed design before building.

https://en.wikipedia.org/wiki/Waterfall_model

https://changelog.com/posts/waterfall-doesnt-mean-what-you-t...

(Links to the 1983 paper within both links)

However, waterfall can be disasterous for the organization. If a single big iteration takes a year, the entire team might be building something worthless for an entire year without getting feedback that what they're doing is not what the users want. I've been on such projects.