An observation.

Agilists are better at explaining waterfall than Agile.

Most Agile textbooks start by explaining waterfall ,and then explain Agile through the lens of waterfall.

This approach is the source of much confusion.

First of all, you don't need waterfall to explain Agile.

Second of all, if you take all those descriptions of waterfall and Agile, you will see more similarities in the way waterfall is depicted than in the way Agile is described.

That tells me there is far more agreement on what waterfall is than what Agile is.

To underline this point, let's call out some silly distinctions that have been invented and aid in the confusion:

• 'Being Agile' is more important than 'Doing Agile'

• 'Agile' vs. 'agile'. Yes, the only difference is the capitalization

• Agile is a mindset

Instead of over-complicating Agile and making it into something ethereal that transcends everything, we should remind ourselves that Agile ways of working already existed long before the Agile manifesto.

You don't need the Agile manifesto to talk about Agile. Auftragstaktik, as practiced in the German army more than a hundred years ago, immediately comes to mind.

The Agile manifesto planted the flag for ways of working that already existed, both in the realm of software development and outside it.

That's why you shouldn't need the Agile manifesto or waterfall to explain Agile.

Most of the noise and different explanations come from the fact that practitioners have to piggyback on these two artifacts in order to be able to explain what Agile is.

When you need those two artifacts to explain Agile, you don't understand it well enough, and that's where most of the confusion comes from.

And when you understand it well enough, you don't get why we're making so much abstract fuss about it.