> 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 absolutely don't think we need a single precisely defined process that will work for everyone. That's scrum and it's shit.
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 )
> for instance just explaining why is it important to iterate faster. I've gotten lucky explaining it once or twice; but mostly I think it needs to be something someone experiences somehow.
Agreed, your "once or twice" is once or twice more often than my success rate at that. You're better off finding an employer who already gets it, and hoping that they don't forget.
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.