I think there's a fundamental misunderstanding of agile. Agile isn't Scrum, agile isn't Kanban, Agile isn't even really the manifesto. Agile is, like lean manufacturing (one of its inspirations), based around one really simple concept: the workers know the most about what they are doing and should be leading the charge on what they are doing.
If your agile ceremonies end up being all about giving management control -- if your story points are used to tell management how much work is getting done, if management is using the daily standup to make sure people are on-task instead of being about commitments. If agile is just another way for management to exert control over software development, rather than being about ceding control to software developers, it won't "work."
This is the same thing you see with lean/TPS, by the way. The joint GM/Toyota venture showed that without committing to these principles, adopting parts of TPS don't really deliver the full benefits.[1] As one UAW team leader said about why working for Toyota was preferable to GM:
> The GM system relied on authority. People with rank, the managers, ruled regardless of their competence or the validity of what they were saying. It was basically a military hierarchy. At NUMMI rank doesn't mean a damn thing. Standardized work means we all work the objectively best way to do the job, and everyone does it that way. I might make some minor adjustments because of my height, for example, but I follow the procedure as laid out because it makes sense. We're more like a special forces unit than the regular military hierarchy. Management's delegated responsibility to the people who do the work, and that gives workers a sense of pride in their jobs.
If management is asking the developers to adopt agile, but they aren't doing anything to adopt agile themselves, good luck.
1) https://www.researchgate.net/publication/245862516_Democrati...