To me that approach goes against the original principles for agile, especially "Individuals and Interactions over Processes and Tools". I'm not a huge fan of highly structured Agile and scrum processes. But I think the best agile implementations come when teams have ownership over their own agile processes.
And if the team truly has ownership they are responsible for their success or failure. Sure, their process may be objectively bad, but that doesn't mean a better process should be imposed from outside of the team. The team should have some level of trust to fix it.
I also disagree with your three points being hard requirements. They may be really good suggestions for teams doing scrum, especially in lower trust environments. All three are specifically for scrum, for instance they lose meaning if you aren't doing sprints. But that's just arguing semantics. Fixing compromised scrum isn't strictly necessary if the team can be successful by dropping scrum.
If, for instance, you’re not doing time-bounded sprints, you are objectively not doing scrum. Scrum has an implementation guide that outlines this.
https://scrumguides.org/scrum-guide.html
> While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Many people borrow ideas from scrum for use in their homegrown agile solution, and that’s ok. But it’s not scrum.
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.