Truth be told, this week I got a tiny bit tired of explaining that "agile" and "waterfall" are not equally valid delivery styles, but radically different theories of how things get done in the world
Empirical or predictive? Leaders, you've got to pick a side.
Do you want to create a learning organisation in which everyone is in touch with users and the environment, at a sustainable cadence of continual improvement?
If so, agile principles are your friend and your guide, not just for building software, but for the whole way you make strategies and shape portfolios
Internalise these values if you want to benefit from modern user-centred design, self-organising multidisciplinary teamwork, and modern engineering practices
Of course there will be exceptions, but it's nearly 2020 and they get fewer by the day. Most everything is instrumented. Software is eating the world
"What if we're building a bridge," did I hear you say?
1. You're probably not
2. You never know what you'll find until you start digging
3. Even bridges come with stress sensors and smart motorway signs these days
And a footnote on the origins of "waterfall" in a 1970 paper by Winston Royce
Dr Royce drew the original waterfall to illustrate a set of problems which he proposed to solve by...
Of course, Royce was working at a time when code and compute cycles were many orders of magnitude more costly than today, so he was unable to extend the full benefits of iteration as far as continuous delivery to users
Unable to easily cut production code, Royce advocated 'simulation' to reduce risk: "... the pilot effort could be compressed to three months perhaps... [the personnel involved] must have an intuitive feel for analysis, coding, and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives... and finally arrive at an error-free program."
Agile understands that we always learn by doing. Either unintentionally, clumsily and expensively. Or intentionally, with control, and efficiency.
The choice is yours