Earlier quoted context omitted.
Maybe that's how it works if you are doing it "right". But nobody ever seems to do Agile "right". If Agile is so hard to do right, and breaks down so badly when it's done wrong in a small way (like letting your manager in the scrum), then isn't that in itself a problem with Agile?
I don't see a problem in a manager participating. But what would the manager do if backlog is handled by the PO and work load by the dev team? I think any process would break down if a manager decides to fly solo and push extra work outside the framework, for example.
Not that all of this would have magically gone away if we weren't an "Agile" team but it did contribute to the problem. "Proper" Agile just doesn't fit well with the way most companies want to run their teams. So managers take Agile and make their own personal tweaks to it. Since their brand of Agile has 80% the same rules to what they read in the book, they expect to get 80-100% of the benefits of Agile. Any questioning of the actual results of this system is heresy, since Agile is a well-established management method used by many successful companies.
If that manager had picked up a management system that worked within the company's framework without making so many changes, or if there wasn't so much Agile-worship in the industry that an "Agile" setup was politically unquestionable, the situation would have been a lot easier to fix. As it is, it wasn't until our team completely collapsed that the company reassigned half of that manager's responsibilities to a new department, and the manager decided to retweak their personal brand of "Agile". Even that is probably too little too late; more and more projects are being moved from that dep't into others, to the point where I'm wondering what the devs there will actually have left to do.
So yeah. I'm very skeptical of anything calling itself "Agile", because it's such a nightmare when done wrong, and I'd bet dollars to donuts there are more places doing it wrong than right.