Saying goodbye to Agile

Ask anyone with 30 years in the industry whether "agile", for all its problems, was a force for good or bad, and the answer will be an emphatic Good!

If nothing else, it gave us ammunition to argue against the impossibility of delivering a fixed thing in a fixed amount of time - which was the universal view from senior stakeholders of what competent software delivery looked like.

The same is true of software. At first you try to make software, and you do, and it's kinda easy. Then you try to make more advanced software, and it seems much harder than it should be, as what you think will work doesn't. You spend a lot of time changing your design to make things work, which ends up not being exactly as you thought it should at first. Finally, after you master software development, things get easier and work like you expect.

In both cases, when you are ignorant, you do the wrong thing, and it works despite your ignorance, because you're doing an easy thing in the most straightforward way. But then you get cocky and try things that aren't as easy, and suddenly the straightforward way doesn't work anymore, because complex things never work the way you expect. Finally, after you've screwed up doing the thing enough, you remember what not to do, and now you can do it without the mistakes. But you're just not-screwing-up the things you already screwed up once before. You'll still screw up new things, because you haven't learned them yet. And you'll screw up again when you forget a past screw-up.

What separates the woodworker from the software engineer is, the woodworker doesn't make a lot of different things, and doesn't use a lot of different ways to do it. The software engineer is constantly doing new things, in different ways. So the software engineer is perpetually rising to their level of ignorance, while the woodworker stays mostly within their level of competence.

This is why there is no system in the universe that will be better than any other at software development. Agile, Waterfall, or anything else, doesn't matter. As long as you keep doing new things, you'll never not be screwing up. But stick to one thing and master it, and it doesn't matter how you do it.

I think you are purposely omitting the fact that those failures have root causes that come from violating key Agile principles.

Things like "we started a project without a big design upfront and we accepted all of the product owner's suggestions, but whe were overworked and ran out of time, and the product owner refused to accommodate requests, and when we finally released the product owner complained the deliverable failed to meet the requirements and expectations".

This scenario is very mundane and showcases a set of failures that are clearly "not doing enough Agile" because it violates basically half of them.

> The solution can never be at fault, it's your execution, or your devotion to the process (in this case) that was faulty.

Agile is a set of principles focused on the process and its execution. What compels you to talk about Agile and pretend that processes and execution are anything other than the core topic?

If your stakeholders change requirements but don't change allocated resources and fail to stay up to date in the daily affairs to monitor and adapt, how is this anything other than glaring failures to adhere to basic Agile principles?