> Anyone that says you can follow some process to ensure success

I'm going to argue this on both of its implications.

Firstly: Agile is not about ensuring success. It's about greatly increasing the chances of success, and minimizing failure from fallout. No amount of process will rescue you from truly dreadful technical team, but so what? Plenty of processes will almost guarantee failure with the best tech team and will in the world.

I'm going to go for the assumption that you knew that already, though, and are attacking the idea that a management-related solution can help in the solving of technical-related problems.

Take a look at a modern hospital, and you will see layer upon layer of 'management' solutions to support medical problems. Prescriptions are checked by the doctor, checked by the pharmacist, and then checked by the nurse. Do hospitals throw these rules away with sufficiently good doctors? No. Do hospitals do this because they think their doctors are shit? No.

Agile can be a highly effective management solution for supporting technical development. I know this because it has been for me, on many occasions, with many different teams, in many different settings. I've also seen it badly implemented to the point where it's an impediment to teams, but ... so what? That's a risk with any process.

Agile and other processes go much much further than your contrived example of checks and balances in a typical hospital. It would be like hospital directly interfering into the daily doctor/patient interaction or say stipulating that no surgery can be longer than 2 hours. You want to do 9 hour heart transplant surgery. Sorry, can't do that. Break it up into 2 hour chunks and measure progress after each to make sure you are going in the right direction.

This is why agile is like religion. It is so vague and so thinly disguised into general meaningless correct sounding "principles" that it can be anything to anyone.

You're messing up agile and Scrum. Scrum has the restriction that every task has to fit within a single iteration. And even with scrum, that limit is self-proscribed. If you regularly have tasks that dont fit in a single iteration and you can't cut those down to smaller tasks then you're free to choose longer iterations. Scrum just says "make iterations, measure progress during iterations to get an estimate how much you can fit in the next." It's like doctors measuring how long they usually need for heart transplant surgery and applying that knowledge to the operations plan for the next week. I'm sure they do. And I'm sure they limit the time they have in the operation room and won't schedule a non-critical long operation at the end of a packed day. (I actually dated a doctor for 6 years and they surely did - apart from working tons of overtime and other unsensible things)

I'm not really confusing the two, I know perfectly well the distinction. However, agile is usually sold exactly like that, as a solution that will improve/solve problems.

Generally, few teams in any organization have so much autonomy to choose their own process. If they did and they decided on their own to do some kind of agile, so be it. But agile is usually imposed externally (because it's in currently) but so is any other process. By the way I'm not criticizing agile per se, I'm criticizing the idea of process as solution.

But then your issue is not with "agile" or "scrum", it's about how people abuse the notion of agile or scrum. It's the same with every other tool, programming language or process. They get abused by people pushing their agenda.

I've seen organizations that started calling their lack of planning "scrum" because that sounded better than saying "d'oh we just make up our mind on what to do every couple of days." But that's not scrum or agile and it's not the fault of people applying or promoting proper agile techniques.