Is agile development dead?

For some time now articles have been appearing explaining why agile is dead, why it is not dead, why the failure rates mentioned in a study are or are not correct and whether or not we hate agile software development.

What they often share is the fact that the article in question was not written by a developer. They are usually all based on this article on the topic.

First of all, we can make something crystal clear. The absolute majority of agile software development (especially in corporations) is not agile. Not even close. It is an elaborate circus through which parasitic business models finance their existence, in which management is buying these tools and developers are told by (usually) non-developers how development works. In general ... of course. And uniformly for every project ... naturally.

This is not about agile software development, but about selling services and products. And unfortunately they are actually overqualified because they know how to convince management. This agile development is what managers imagine it to be. It has absolutely fuck all to do with agile development.

Developers don't have a problem with agile development but with the abomination that these parasites and their own companies make of it. Because these agile methods fit well into the companies' management philosophy. This agile development is much more about management and control than it is about development. You can pretend to be agile, usually increase the output and still have all the nice control freak bullshit on board. 10/10 for management.

If you are supposedly developing in an agile way and regularly ask yourself why the fuck you are sitting in this pointless meeting or why that guy is around again, then you are not working in an agile way. You are also not agile just because you use Scrum. Scrum is one way of organizing agile work. One of many.

Developers who hate agile development usually hate it because they don't don't really work agile. They sit in pointless meetings, are harassed by people who have no relevant function and add absolutely no value to the project, work under technical and organizational conditions that could hardly be more rigid and that nobody needs in the first place. This form of agile development is madness coupled with ... let me run the number real quick here ... a shit ton of wasted time. The output usually isn't actually higher.  How could it? The difference is usually only in the frequency with which features are rolled out. This also happens faster in these variants. Provided you don't fall into those 268% eventually.

And that's why this study is perceived quite differently. Those who are actually agile have no idea what could be going wrong and how these claims could possibly be realistic. Anyone who does work under the above mentioned conditions on a daily basis knows this very well.

There are projects for which agile development is out of the question. For the majority of projects agile development is well suited and you can take advantage of the considerable benefits. However, this requires that you are actually agile. How you get there ultimately doesn't matter. The most reasonable approach (if customers are involved) is to adapt an existing agile method to the project and thus become more agile. If you don't have the customer problem, you have free choice.