To be fair to agile though, I can see situations where it can work. The problem is that many of its adherents seem to see agile as a hammer and all software engineering as various forms of nails.
Agile isn't a methodology, but a metamethodology -- or, in terms of the metaphor, it isn't a hammer, it is a set of guidelines to use in selecting tools.
Scrum is a hammer, but Scrum ≠ Agile. Often rigorous adherence to particular methodologies (usually Scrum) get misidentified as being "Agile", but rigorous adherence to a particular methodology is not only not the same as Agile, but is directly contrary to Agile principles (particularly, its a direct violation of the first value from the Agile Manifesto, "Individuals and interactions over processes and tools".)
While I agree that this is against the agile manifesto, that's no excuse. This is how it ends up getting implemented in large corporate environments, a lot in fact, so methinks the agile fans ought to take some ownership of this recurring problem and either find a solution or stop shoving agile down everyone's throats.
Finally, I'd take a 30% pay cut to escape agile to do exactly the same work I'm doing right now minus scrum. I'd get more work done and I'd feel better about it because I would no longer feel like I have the engineering equivalent of an ankle monitor attached to me. That's more than worth the loss of compensation to me.
This is not a problem with Agile; anything that works anywhere will lead to imitations that steal the name and attempt to extract some simple recipe from the "lessons" of that thing that worked.
> While I agree that this is against the agile manifesto, that's no excuse. This is how it ends up getting implemented in large corporate environments
No, its how something that is nothing like Agile gets implemented in large corporate environments and called Agile.
Fundamentally, this is a symptom of a broader leadership culture issue environments in the authority structure and culture has people that neither know nor care to know about the domain have authority for decision making within that domain, and its certainly beyond the power of people external to the affected organizations with an interest in particular approaches to problems in any given domain (software development or otherwise) to do much about. It is, however, a pervasive problem in large bureaucracies (not only corporate ones.)
But instead it has become an enormous metastasizing moneymaker for minting Certified Scrum Masters, Certified Scrum Product Owners, Agile Certified Practitioners, and all sorts of other Agile titles for $1000+ a pop. So I guess we're going to have to disagree because I think this means a little ownership of the issues that arise in the practice resulting from that training is appropriate here. Because what I'm hearing from you now sounds a lot like the usual "You're doing it wrong!" refrain which accomplishes precisely nothing.
As long as there are people looking for packaged solutions and willing to pay top dollar for them, there will be people willing to sell them to you under any name that you ask.
But if the name on the tin is refers to something diametrically opposed to that kind of packaged-solution approach, well, its probably not going to be an accurate label.