That can be fixed by defining something new, more precisely.
I do not think that we're going to find a single precisely-defined process that will work well for everyone.
The strength of the OG Agile thinking was the iterative, "inspect and adapt", "shorten the feedback cycle" thinking. Which is somewhat in opposition to your desire for a precisely defined process. The Agile manifesto specifically stated that "process" was one of the "items on the right" that had less value.
So what you propose is not a fix to it, it is a different mindset. It is process-first. And because it is a more rigid and inflexible, it is less suitable to the business of software.
I think we just need some criteria which can provide clear answers to whether you're doing agile or bullshitting around or doing cargo cult agile. The manifesto/principles aren't that but they should have been. Instead they were some sort of vague inspiring motivational bullshit. "Build projects around motivated individuals!". Yeah, ok whatever. No mention of the word iterate though.
My proposal isn't a different mindset. I actually think I have the same one as you because when I think "agile" my interpretation centers more around short feedback cycles and iterative development. I use those words. People who have done it use those words. The manifesto doesn't. The CEOs who want to bring in "agile consultants" while still keeping quarterly milestone planning sure don't. They think it's a kind of software they install in their devs are are generally oblivious to the idea that it means they have to change too. The fact that they do needs to be brought into sharp focus. The fact that the consultants who promise them waterfall in agile clothing are bullshitting needs to be brought into sharp focus.
My proposal is to codify more precisely the things which make "agile" "agile" so that it becomes at the very least harder if not impossible to bullshit about it. I'm not suggesting making it less flexible. I'm suggesting we describe what it is in a way that we can categorically rule out what it isn't.
And then give it a different name, to avoid all the baggage from the old one. Some name I can point to and say "we need to be doing that" which rules out at least 95% of the bullshit artists.
It turns out that iteration (and recursion) are pretty mind blowing concepts to have to explain to people. Like for instance just explaining why is it important to iterate faster?
I've gotten lucky explaining it once or twice, [1][2]; but mostly I think it needs to be something someone experiences somehow. Either by programming or engineering or some other way.
[1] Some engineers understand what a control loop is, and you can explain why iterating (faster) actually leads to better precision than trying to measure things precisely in one go inside the loop. ( https://en.wikipedia.org/wiki/Closed-loop_controller )
[2] You might be lucky to find a manager who really understands PDCA or OODA. https://en.wikipedia.org/wiki/PDCA , https://en.wikipedia.org/wiki/OODA_loop . Unfortunately these are also somewhat prone to cargo-culting. On the "upside", OODA cargo-culting may be subject to natural selection.
I find it perfectly precise in what it tells you what you need to optimize for. It just doesn't tell you how because it couldn't possibly know. But finding out is hard work.
What the fraudsters are telling you is that you don't need to do any of the things in the manifesto because they know everything already. A general lack of industriousness on the part of software companies is really what makes not just Agile, but the consulting space in general, ripe for fraud.
https://agilemanifesto.org/ does this look like a clear and precise proscription for a good way to engineer software? Or does it look more like a bunch of "inspiring quotes" from a discount southern baptist church website from the 1990s?
I learned this the hard way when I was younger when I tried to write some tests for some bugs and my boss told me that we needed to deal with it with meetings instead. People over process he said. I actually couldn't argue with that.
I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process and not just a bunch of magic incantations to do that, like the enterprise world seems to think.
Alternately, a different thing the customer might want is to Solve Their Problem; which is a fundamentally different thing, and requires a fundamentally different process.
The Agile manifesto doesn't say anything about the former because it would defeat its own purpose.
