This feels like a rant that does not make any substantive points and ends up looking like an example of what it sets out to criticise.
> Sprints seem to put people on the wrong foot as if we should rush to complete everything in the Sprint...
This is arguing about semantics. If you don't like the term, use another one or explain it better to your team. The important thing is to understand the point, which is to have short development cycles with working software at the end.
In context, the term "sprint" does not refer to any sense of rushing but rather of uninterrupted focus. Of course you plan and reflect before and after, but once you've started you go the distance (which is short!) until the end.
> Lots of talk about how to do better Scrum, while Scrum should be in the background.
That's not inherent to Scrum. On the other hand, continuous improvements have to require an amount of discussion on what works and what doesn't in order to adapt and improve. You need to find the right balance.
> The Sprint Review is mainly misunderstood, as the label is confusingly similar to Sprint Retrospective, and people mistakenly believe it's a Sprint Demo...
This is again arguing semantics and also saying that the team does not understand what they are doing. Hardly a problem that can be attributed to Scrum.
> The Product Owner rarely owns anything and mostly accepts requests from the Product Manager or other stakeholders.
Perhaps the product manager is the right person to fill the role of "Product Owner", then? The role does not have to be a dedicated person...
I don't want to give the impression that Scrum has a "get out of jail free card" here. Most criticisms of Scrum are very superficial and do not actually criticise the essence of Scrum so of course the response is indeed often simply that "you're doing it wrong"...
Scrum is not a panacea, on the other hand one should always try to understand the essence of any framework, the point, instead of being hung up on details and semantics. A good starting point is to read the Agile Manifesto and to think about the point.
> Sprints seem to put people on the wrong foot as if we should rush to complete everything in the Sprint...
This is arguing about semantics. If you don't like the term, use another one or explain it better to your team. The important thing is to understand the point, which is to have short development cycles with working software at the end.
In context, the term "sprint" does not refer to any sense of rushing but rather of uninterrupted focus. Of course you plan and reflect before and after, but once you've started you go the distance (which is short!) until the end.
> Lots of talk about how to do better Scrum, while Scrum should be in the background.
That's not inherent to Scrum. On the other hand, continuous improvements have to require an amount of discussion on what works and what doesn't in order to adapt and improve. You need to find the right balance.
> The Sprint Review is mainly misunderstood, as the label is confusingly similar to Sprint Retrospective, and people mistakenly believe it's a Sprint Demo...
This is again arguing semantics and also saying that the team does not understand what they are doing. Hardly a problem that can be attributed to Scrum.
> The Product Owner rarely owns anything and mostly accepts requests from the Product Manager or other stakeholders.
Perhaps the product manager is the right person to fill the role of "Product Owner", then? The role does not have to be a dedicated person...
I don't want to give the impression that Scrum has a "get out of jail free card" here. Most criticisms of Scrum are very superficial and do not actually criticise the essence of Scrum so of course the response is indeed often simply that "you're doing it wrong"...
Scrum is not a panacea, on the other hand one should always try to understand the essence of any framework, the point, instead of being hung up on details and semantics. A good starting point is to read the Agile Manifesto and to think about the point.