this applies to many other instances of systems being adopted and appearing to succeed even though what's really behind the success is something else, but because we don't have the control we associate the system with the success, like how when it's reported that a successful person eats chocolate or wears red; they were successful and they happened to wear red and it was only coincidence. Humans are always looking for causes and will associate spurious things together by default. I bet you if Agile were removed from all teams tomorrow they'd still deliver.

Agile is often more bureaucratic overhead. More meetings, more checking in.

At the risk of "no true Scotsman"...

If it's creating more overhead, it's not agile. It may wear the label, but it's not the real thing.

If the existing process was already the optimal one, the agile thing to do is to not change it. If the "agile" changes are adding overhead, the actually agile thing to do is to go back to the previous process.

So basically the definition of agile is:

"The perfect way to do project management"

With this definition in place the future is solid, no criticism can bring agile down because agile can evolve into whatever you want it to be.

Literally, what is the difference between "agile" and "whatever works"?

Agile is "adjust your process". Your process is one of the variables, not something handed down from on high. If you aren't adjusting your process, you aren't doing agile.

Many places say "We will be agile according to this rigidly defined process". The contradiction is obvious.

"Whatever works man, whatever works." lacks deliberateness, and that's one of the key differences between it and agile (little-a to keep separation from the Big-A Agile sold by consultants).

Look at the difference between the principles of Theory of Constraints, and what most organizations do. Most organizations want to remove constraints, they know they're a problem (since, well, they're constraints). The difference between ToC and what most people do is that ToC emphasizes a deliberate focus on the singular constraint in the process. I've seen teams and offices optimize the hell out of areas that aren't the bottleneck. Meanwhile, they still spend 3 months at the end of their projects running their massive, manual test suite. Do the tests bring value? Yes, immense. Do they bring value at the right time? No, because they take 3 months to run so they're delayed until the end of the project, so the project schedule leaves 3-6 months of buffer after that testing to conduct rework. A deliberate focus, then, should be brought to the testing activities and identifying how they can be conducted more rapidly, ideally automatically, and feedback brought in at an earlier stage.

Agile, as described in the manifesto, brings in a set of values that are intended to provide focus on what's important for both the team and the customer. To a large extent, it means "whatever works", but with focus on the values you share with your team and customers, and the tradeoffs that will be incurred based on the choices made.

If deliberateness works then it works man. Whatever works.

More touches, yes. But the incrementalism-centric approach of the daily standup (which should be kept quite short) should lessen a lot of overhead/BS from filling out reports (or the like) post-fact; cards are kept up-to-date and problems (FUDs) discussed early and often. No one is making up what they did 3 weeks ago because they can't remember, and it is very clear when something is stuck or making progress.