The us vs them mentality between Agile and Waterfall that coaches often preach is itself a violation of the agile principle of people over process. You should identify what process best fits your product/customer/team, then use that process. Some products require lots of upfront requirement elicitation before you can even identify the appropriate solution-- and that's ok. Imagine prioritizing a working software in a sprint over figuring out what your customer needs.

I recently observed from the outside a project that took upwards of two years of requirement elicitation, IP contracting, complex distribution of ownership between multiple competing companies, multiple OS's, complex hardware platform design revisions to support the intended software functionality. Not a single line of code was written for two years. Was this state of the art engineering? YES. Did they operate under the principles of the agile manifesto? YES.

> waterfall is a strawman. any pre-agile organization that signed off on a two-year plan and showed up two years later saying 'where's my thing?' is just as much of an idiot as they would be today.

It's not a strawman. Those organisations are very real.

> yes, making plans that you indend to continuously adapt to the situation at hand doesn't conflict with agile. but that still leaves one wondering what agile really brought to the table. time boxing everything at a fixed 2 week interval?

Agile emphasises that you need to deliver something working to the customer, every 2 weeks. Without that it's very easy to call something code-complete or tested but not released or whatever, and you get further and further behind where you think you are because none of the stuff you thought you'd finished actually works.

I do mostly agree. I'm speaking in broad terms here. Most effective software developmwnt for moat of software development history has probably run off some bespoke to the organisation hybrid of something resembling waterfall in some cases and resembling agile in others.