One of the writers of the Agile Manifesto has come out and stated that Agile is largely a failure:
But in the 14 years since then, we‘ve lost our way. The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flaccid agile,” a half-hearted attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they've forgotten their aim.
And worst of all, agile methods themselves have not been agile. Now there‘s an irony for you.
This is essentially true. I think that anyone who has ever worked in an "agile" environment and has studied the agile principles understands that very, very few places approach anything resembling those principles, regardless of what they claim. Mr. Hunt identifies a few reasons why, the most important of which I believe to be is the Joy of Rules. But even that is not sufficient to explain why agile has become just another buzzword.
Modern enterprise development is nothing but a collection of rules. Project Management Organizations exist because people believe that if you follow a set procedure every time, then you will get largely the same results every time. This is why Scrum, I believe, is so popular. It can be devolved into a set of hard and fast rules that align with the PMO bias towards hard and fast rules. In large organizations, deployments and server maintenance are often out of the hands of the development teams and are even occasionally separate deployment and server support teams. Finance wants to understand what is being purchased with the money they give out, and so demand detailed scopes and ROIs before projects start. UX designers want to understand the whole product to fully flesh out a robust user experience. Architects want to understand the whole system before making crucial decisions. None of those constraints lend themselves to a truly agile environment.
Now, the rules that other departments follow are not necessarily pointless. The PMO is correct that repeatability is important, even if how they go about getting that repeatability is often flawed. The designers lives are made easier if they can design the whole product up front, even if that design is usually brittle as new needs arise. Operations does have a responsibility to protect the overall infrastructure from individual projects/products. Finance has to ensure that the company can take proper advantage of the tax laws (specifically the capital depreciation). All of these groups have reasons, and sometimes the reasons are even good, for doing what they do. Which is the problem: Agile has been sold as a development process, not a company process.
Agile has definite advantages for the process of creating software based products. It is clearly superior to waterfall processes when looked at from purely the perspective of creating the product. But creating the product, at large organizations, is not the only concern (it is not always the primary concern even). Agile cannot work unless the entire company changes how it behaves. And since Agile has been primarily a development process discussion, it hasn't really spent a lot of time on changing the culture outside the development organizations.
And doing agile in other areas is hard. It is complicated for finance to figure out what to depreciate after the fact. If you make a true product team that encompasses every area, what do you do with the finance people? Do they handle the budget? Then what happens to the project manager, now that she doesn't have that responsibility? Does your architect spend all of her time doing POCs and tech spikes, or does she write code? Is it the best use of resources to have your OS engineer spend all of her time on one product? All of these questions have answers, of course, but most of those answers involve rethinking how we best make use of people and most of them run counter to the way certain disciplines see themselves and see how they best work. Frankly, agile proponents have given them precious little reason to think about why those "best practices" need re-thinking, especially form their point of view. Unless and until that happens, agile is just going to be seen as some meetings that developers hold with some business people. That is why agile is failing, because it hasn't broken out of the developer ghetto.