Much of what is said here about agile could equally be said of devops, a term that's been drained of whatever blood was pumping through it to the point that it functionally doesn't mean anything anymore.
I mean, somehow we went from A to B here and it's reasonable to ask what the hell happened.
I suspect very strongly that the real answer is that we're seeing the scattered, burning rubble of a scorched-earth epistemological and semiotic warzone here, where process burden after process burden are being thrown in the path of those who seek understanding and nearly intimacy by people whose whole id and purpose depend on the ongoing primacy of command-and-control as the operational zeitgeist
The same general shape of thing happened to DevOps.
The core insight of DevOps was that if you have to carry the pager for the code you're writing, you'll make better software. It was, if in some near trivial way, an way to shackle the quality of a developer's life directly to the failure cases of their software.
In retrospect, it was clear that idea would not be allowed to live.
So what we call DevOps today - functionally "vendor contract micromanagement via CLI" - is not that at all.
In both cases, it's worth thinking about where the original Agile and DevOps philosophies position their adherents. Because in both cases, that position can be fairly described as "as close as possible to the consequences of, and people affected by, decisions made about software".
And in the same vein I think it's worth asking ourselves who, specifically, are well-served by debasing and diluting those ideas, by distancing people and pushing responsibility and agency away from consequence.
@andy@mhoye if an exec is the auteur of the Big Idea Project, then early external/reality feedback that it's not likely to succeed in its business outcome target turns it from an Execution Problem into a Exec Problem. http://webseitz.fluxent.com/wiki/AuteurTheory