Doing things in a list which allows reorder, choosing which items in that list will get done per time period, and communicating that in short time periods. That is a methodology of management which embraces change, not micromanagement. Scrum doesn't micromanage, managers do. If you are being micromanaged, quantify the overhead of meetings and planning vs. the amount of time being derailed or working on things that wouldn't have been prioritized. You may get more done without management, but is what you are getting done what needs to be done? That is what Scrum is about.
I think XP's original stories and tasks on note cards in planning meetings were a better way to shorten tasks than Scrum leaving that open though- time estimation can be a problem in Scrum without proper planning.
And yet some have had great success with Scrum as their process.
How's this for an alternative experience: I was coaching a Scrum team once (note I'm not an agile consultant, I just happened to be in the wrong place at the wrong time) and it led to fewer meetings. The rule was there was one fifteen-meeting standup meeting daily, and otherwise all team members were freed from meetings - they worked on delivering software 80% of the time.
Most communications were short impromptu discussions in the product room related to the current sprint, where devs could talk to the product owner, or the business analysts, or the testers, (who were all living in that room too), or the come-and-go liasons that were protecting the core team from meetings with the outside organization, etc.
Sometimes the impromptu discussions led to longer design or requirements discussions as the product owner/biz analysts taught the solution domain to the developers, or the developers explored the constraints or opportunities to rework parts of their architecture to the product owner. These were focused primarily on the current sprint needs with an eye on the overall backlog to detect if big features were coming, or there was a need for a major refactoring or architectural change. I wouldn't call these "meetings": these really were "design sessions", probably the most integral part of building working software.
After each two-week sprint there were 3 meetings: on Friday, a one-hour demo for outside executives to see progress, a one-hour post-mortem ("how would do do things better, what technical debt did we accumulate, etc.") , and on Monday, a two-hour planning session for the next sprint (which replaced the usual standup).
That's 8 hours of "management meetings" in an 80 hour period, or 10%. Not bad, in my experience. The other 10% would be for personal stuff that happens (doctor's appointments, everyone gets distracted by a YouTube video, mandatory town halls, etc.)
So, combine the above with a bunch of stickies on the wall to track progress, a backlog of features, and (most importantly) a product owner with authority to make decisions... that's Scrum, in my experience. There's really not a lot to it.
I don't think this is what you likely experienced. What did you experience that you hated? The hardest part is having a product owner take responsibility for the priorities & trade-offs, that also has enough clout or political protection in the broader organization to make (potentially wrong) decisions. If you're missing that, you get meeting explosion, as people point fingers and spin their wheels.
