If you do Scrum like that, you're doing it wrong (I know, no true Sctosman [1], and I know, there are actually dark patterns [2]).
I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong.
Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.
But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job.
You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start.
And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.
Bingo. That is the key point to me. Scrum, and other agile-family methodologies, are great when fully implemented. But what usually happens is that the higher-ups refuse to relinquish a bit of control, and stick tightly to their traditional command-and-control approach, and the dev teams are forced to do something that looks-kinda-like-scrum (or looks-kinda-like-XP or looks-kinda-like-AUP, etc.) while operating in a structure that isn't really compatible with the principles of Scrum, XP, AUP, etc.
Basically, we're forced to try and fit a round peg into a square hole because people higher up the org-chart either don't really understand agile-family methodologies or are actively opposed to truly implementing them.
Nail, meet head. I've worked in places where scrum has worked great. But most places I've worked at or heard about have exactly the problems you describe.
That sounds ridiculously similar to people hanging on to communism/socialism: "the principles are sound, it just hasn't been implemented as intended". Except, just like communism, Scrum has never and will never be implemented "as intended" because that's contrary to our collective evolutionary gifts, and against a developer's desire to find satisfaction in good craftsmanship. A project management methodology building on utopian altruistic ideals and delusions wrt people's motives is just propaganda.
Maybe what's missing in my original comment... What I'm trying to say is that there is a certain kind of organization (mostly traditional / old organizations) who would have these kinds of problems with any agile method.
And there are other organizations who can make any agile method work for them.
So, it's not really Scrum's fault when it fails (at least not always). And it's not really (or not only) Scrum's achievement when it succeeds.
As a friend of mine, Samir Talwar, once said: "To be good at software development, you need an organization that's optimized for software development. Most organizations are optimized for something else."
Anyway, if you implement a process, but ignore even the very short (22 pages) guide that summarizes the process, but instead cherry-pick what you think will work well in your org, then don't blame the process when it does not work.
As I wrote in my book: "But changing Scrum so it works within your company will not make you more agile – It will make Scrum less agile!"
Yes I've also been in SCRUM projects that worked well; however, these projects would have worked well under any organization, because of the particular people on the project.
Yes, when it's worked for me, the team has also been great. What I mean, though, is that scrum was an active benefit to us. The project would've gone well with or without scrum because the team was good, but scrum was helping us achieve our potential over using other approaches (that I know of).
That also sounds ridiculously similar to people hanging on to capitalism: "The free market is the best way to run an economy, it's just that there has never been a free market in the real world."
True. Scrum is mostly propaganda. I have yet to see it work right and it's been more than 3 different jobs now. The closest was at a big corporation where they sent us all the agile training, had buy-in from management, the PMs, everyone and that was great except that high profile project eventually had PMs whose entire jobs involved evaluating burn down charts to track progress within sprints. So yeah, they actually had people who looked across all the many dev teams doing a roll-up of burn downs for management. That was totally bizarre.
I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong.
Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.
But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job.
You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start.
[1] https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-t...
[2] https://ronjeffries.com/articles/018-01ff/hills-to-die-on/
[3] https://www.quickglance.at/agile_antipatterns.html