Sure, and I agree to a large extent, but if I'm doing woodworking and my blades are so fragile that they snap with the tiniest amount of friction, I'm probably not going to be very happy working like that for very long.
But why would you ever intentionally use (or vigorously defend) demonstrably bad tools? Just because you could do well with a bad tool doesn't mean you should or that you couldn't do better with easy-to-get other, better tools.
If you are forced to use an inferior tool like Agile, then sure, you want to make the best of it and be a craftsman who can still succeed.
That is an endorsement of being adaptable and self-reliant as an engineer, not an endorsement of Agile.
And if a tool is bad like Agile, it's useful to point it out and slowly steer the bureaucracy that feeds it into bastardizing whatever the next tool is, but hopefully inching forward to a better global state as well.
I'm an XP fan, but I'm always wary of saying "they didn't do real agile". It can descend into "No True Agile" pretty quickly, with a dash of victim-blaming.
Agile is actually hard to get to grips with. It requires lots of discipline. So did the pre-agile methods that worked best. And it gets half-done for the same reason that the pre-agile methods got half-done.
It's hard. Hard to do, hard to learn, tempting to stop.
Perhaps, but one problem often seen in large orgs (I've been there personally twice, and heard many more stories from close colleagues) is that they adopt the agile methodology (sprints, stories, etc), without adopting the culture shift (shit does not get added into the middle of a sprint, ever) necessary to make it work.
Agile process without agile culture objectively isn't True Agile. It's worse than everything it sets out to solve with the alternatives.
I disagree that Scrum is the whole of agile, so the concept of "sprints" doesn't exist for me. If the product manager wants to rearrange stories, that is his or her business. My business is advising on the relative complexity of stories and then undertaking to deliver the next story in the backlog. The roles are well-defined, after which, we talk to each other like we're adults trying to achieve the best outcome for everyone.
Putting aside that particular nitpick, it's easy to cargo-cult the practices. I sometimes use the analogy of the introduction of lean manufacturing in the US. At first what was introduced were the tools: boards, line-stoppages etc. But tools are just tools, by themselves they're not enough.
The uncomfortable, expensive and difficult truth in our industry is that people, process and tooling are not substitutable. You need the best of all three that you can get.
I'd prefer to say "misinterpret" than pretend to follow... but even so, following it as presented to its totality is still going to be sub-par.
Some of the points in the Agile manifesto are just arrogant, unjustified statements of fact or vague and useless comments.
Some people hate face-to-face interaction... and what the hell is a 'regular interval'... and sometimes a clear vision and direction from above achieves the very greatest of results that the team without it would have failed to produce.
Its not useless, but its not without fault either.
But feel compelled to add: Agile is only a problem when teams pretend to follow it but actually don't.