Most of that revolves around the way retrospectives are handled and the weird way in which "continuous improvement" is viewed. Agile sees this as continuous process improvement, instead of say, people improvement, team improvement, or software improvement. This process for creating process (aka "bureaucracy") has led to retrospectives evaluating things like burndowns, "What about our process went well?" or "What about our process didn't go well?", etc. Scrum has basically a built-in bias to destroy itself: "We've iterated into this super process-oriented way of doing work, and we did it in small steps.... Agile!!!"
I once made a comment that neither I, my company's customers, nor their customers were paid in story points. I still think that is the crux of why Scrum is so broken.
Agility will become more pronounced in software teams when the feedback mechanism ("retrospective") is based upon 1) qualitatively evaluating product success, and 2) quantitatively measuring something that is relevant to the product or business being built and not a peripheral concern like how much work was done or how it was done. Work done, predictability, and even lateness have very little to do with product success outside the realm of contracting.