>We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile', we've got to come up with some new word," - but

>We have to recognize that and fight against it because some people have said, "Oh, we're going to 'post-agile', we've got to come up with some new word," - but that doesn't help the fundamental problem. It's the values and principles that count and we have to address and keep pushing those forwards and we might as well use the same label, but we've got to let people know what it really stands for. The heart of the problem he's describing here stems from the fact that those principles were originally quite vague: * Individuals and interactions over processes and tools (does this mean prefer meetings to writing tests and creating a CI pipeline?) * Working software over comprehensive documentation (don't write documentation? do write documentation? Why not both? Moreover even the most waterfall of companies I've seen have never actually prioritized documentation over working software) * Customer collaboration over contract negotiation (never did encounter a situation where this principle could even be applied... does this phrase use contract negotiation as a metaphor or is he talking about literal contract negotiation?) * Responding to change over following a plan (he actually complains in this article that he never meant "don't plan"... idk) Contrast that with, say "develop iteratively, in small chunks and, where feasible write the test first and release frequently and talk regularly with the customer" -- those are specific principles. If you create a vague set of principles surrounding an idea that resonates deeply with people then the emergence of a "priesthood" that doesn't necessarily agree with your original intentions is somewhat inevitable, no?