The core issue, I think, is that software development remains unpredictable in many very common situations (for a whole lot of reasons, most of which are not technical). Management and planning requires predictability, so we devise systems like Agile to attempt to impose predictability. This addresses the wrong problem: the work itself is unpredictable, no matter how predictably your sprints start and end and how well you fit X% of a project into each sprint. Things improve (in many cases thanks to systems like Agile) until they hit a local maximum constrained by that fundamental unpredictability, at which point planners and management are still unhappy, so more process is imposed, abd eventually we end up in the situation described by this article.

Usually,causes of the fundamental unpredictability remain unacknowledged and unaddressed beyond a superficial level.

I wonder how Apple gets round this?

By never announcing things before they’re ready?

They announced AirPower before it was ready and had to publicly cancel it.

This seems to work very well. Why doesn’t everyone do it?

You get a short-term boost out of announcing something. Some companies feel they cannot wait for that boost until they’re done.

All these new nonsenses are a problem. Those who understand them can also see that they are nonsenses, and those who do not understand them think that they are superior methodologies.

Following the "12 principles" blindly is just as bad as letting your organization be rolled by the "agile industrial complex".

The idea of breaking work up into little chunks is great -- it is in no way contradictory to the ideas in the "Project Management Body of Knowledge" it is just putting them together in a different way.

In fact, those ideas need to be put together in a way that works for a particular organization.

In some cases the most important practice is the reduction of "work in progress", that is, a simple kanban board without a lot of effort into estimates and deadlines. If you have good build and deployment practices you should be able to deploy "whenever the business needs it" and not have to wait for a sprint to finish.

The biggest problem I see is a lack of trust between management and engineering. If that trust is not there it doesn't matter much which management methods you use. With agile you will bring conflicts up quicker, but that just might cause you to burn people out and spin your wheels. If you work on a longer timescale some people might be able to get work done despite the dysfunction.

No, corporate "agile" is the problem. Politics, resistance to change, and power struggles are what's fatiguing. True Agile is liberating and invigorating, but unfortunately rare.

So rare that perhaps the meaning of the word has changed irrevocably?

Disclosure masquerading as a plug: I’m writing this at the moment- https://riskfirst.org

It's the same old bureaucrats who just changed in the "agile" clothes. Because "agile" is whatever form the bureaucrats want to call "agile".

It even shows up as “agile workplaces” these days, where it most often manifests itself as open floor seating with no set arrangements—transient would be the best characterization. FTA, just another example of how the word’s lost its meaning, this time to the buzzword wars.

What do you mean by FTA? I'm not familiar with that TLA.

"From the Article"