Understanding this, agile works fine. But zealots without practical experience want everything to fit the agile religion. And so you get the confusion about how to plan an architecture, how to develop overall system requirements, when everything must be incremental and in sprints.
We had pretty good solutions to many of those things twenty years ago, but that is "waterfall" now, the tarnish used to denigrate everything agile acolytes don't understand.
Agile is a product now, sold by ignorant business consultants. I've never seen a more ridiculous mess than watching a non-software organization trying to transition to 'agile' in the whole organization. Sales, marketing, business process management, doing sprints, with scrums and epics and story point estimation, etc. Yes, that is what the agile industry is selling now, agile for the whole organization, in any industry. The horrors this will produce we have yet to fully enjoy.
This reminds me: I saw SAFe everywhere a few years ago and now I don't see it in the wild as often. It seemed kind of snake-oily to me. Does anybody have any idea what happened when I wasn't looking?
Yes it is. Fundamentally, any project stage that you can finish without delivering a working system to the end user is waterfall.
> Agile is about adapting to change as it occurs - how do you know if there is any change if you didn't start with a plan?
Why do you care whether there is change? The whole point of agile is that it doesn't matter if the customer's requirements change, you'll deliver value to them just as effectively whether they do or don't.
Easy. The designs change. The requirements change. A plan is not a design. A plan is not the requirements. A plan is a step by step description of how you are going to implement the designs and requirements, and in what order. And if the designs or requirements change enough, you now have to throw out that part of your plan.
I think you have a very narrow definition of "plan" that does not correspond to how most people use it.
More importantly, is there a definition of "plan" in the context of software development where my claim fails? The claim that if requirements or designs change enough, some parts of your plan have to be thrown out?
The meaning I used is also a primary definition and often enough the first definition you'll find in dictionaries. [1] [2] [3]
[1] https://www.wordnik.com/words/plan
[2] https://www.thefreedictionary.com/plan
[3] https://dictionary.cambridge.org/us/dictionary/english/plan
Regardless, I'm not particularly interested in the dictionary definition. This is English, and what matters in English is how people actually use the word. You are literally the first person I've ever heard of who believes that "plan" is restricted to high levels of detail.
Developing a plan is not waterfall. Designing an Architecture is not waterfall. Agile is about adapting to change as it occurs - how do you know if there is any change if you didn't start with a plan?
Good plans and designs account for risks and unknowns and anticipate (certain types) of changes and delay locking into assumptions until necessary. But not having a plan or design is not agile - it's failure.