At its best, Scrum can be a tool to limit manager micromanagement (only at the level of a whole sprint), while also empowering the team to work the way it considers most effective because everything Scrum suggests as defaults (like what meetings to have and what their goal is) can be changed by the dev team.
In practice management doesn't give a iota about what Scrum says their role is and everything becomes discussions about what Scrum does or doesn't say.
All that said, Scrum also completely ignores design work.
In my experience Scrum is the worst enabler for micromanagers
- PO suddenly wants to do something yesterday - they just give their task top priority so you're forced to do it
- PO want the button to have that exact shade of teal - they won't accept the story until it looks exactly like what they wanted
- You want to clean up the messy code you're touching - just make a story for it and watch the PO rank it to the bottom (essentially meaning it'll never get fixed) - since it has no 'business value'
This leads to demoralized devs working on crap codebases they're not allowed to fix.
> - PO suddenly wants to do something yesterday - they just give their task top priority so you're forced to do it
That's fine. It's their role to prioritise features. BUT within the framework this should apply to the planning for the next sprint as the point is not to interrupt the current sprint unless there is an overwhelming reason.
> PO want the button to have that exact shade of teal - they won't accept the story until it looks exactly like what they wanted
Nothing wrong with that. It comes down to explicit and clear feature specification.
> You want to clean up the messy code you're touching - just make a story for it and watch the PO rank it to the bottom (essentially meaning it'll never get fixed) - since it has no 'business value'
This situation applies whatever the framework you're using. You need to sell what you want to do by explaining the value, or you do it step by step under the radar. There should also be someone with clear authority over the codebase who can make these decisions and sell them/negotiate with project management. Again this is not Scrum, but software development in general...
In practice management doesn't give a iota about what Scrum says their role is and everything becomes discussions about what Scrum does or doesn't say.
All that said, Scrum also completely ignores design work.