I don't think that's a fair assessment. There
are definitions of scrum methodologies. I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't
actually follow one of them. All of them "compromised" with other business interests, and typically the compromise was on the "hard to follow" parts -- the core tenets of scrum! Some of them were 100% waterfall, but with scheduled meetings bearing titles that mimicked scrum processes. These aren't "people doing scrum wrong", these are people in a cargo cult.
I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful.
How many of your bad experiences with scrum bent more than a couple of these rules? How many were always followed? : https://en.wikipedia.org/wiki/Scrum_%28software_development%...
Some big things I've learned are:
* Sprint planning has to be mutual. Management cannot plan a sprint on their own, they do not have enough information to accurately plan for order or operations or effort required. Furthermore, participants need to understand the direction and priorities of the project in order to do their job properly.
* You cannot change a sprint that is in progress. Mitigating switching costs are a huge part of the benefit scrum provides. Compromising on this defeats the point of the process. It's hard to tell management "no", but you have to do it. If fire-drills are unavoidable, then you must to account for this time when you plan a sprint.
* All stakeholders must attend backlog groomings and sprint reviews. If the inputs to the process are guesses, then the outputs will be guesses. This is just as important when prioritizing work items as it is when giving feedback on completed items. It must be first-hand. Documentation and/or status updates simply do not even come even 10% close to the power that a live demo does.