When Scrum doesn't work, you’ve got three options:
1. You did Scrum the wrong way.
2. You did not supplement Scrum with the right practices or you supplemented it with the wrong practices.
3. You're using Scrum in a context where it shouldn't be used.
The notion that Scrum doesn't work or has flaws built-in is considered absurd.
Scrum is a perfectly incomplete framework. Basically, if it doesn't work, the general consensus is that you just don't get it. Scrum, as a purposefully incomplete framework, has a perpetual ‘Get Out of Jail Free’ card embedded that protects against all criticism.
It’s not supposed to tell you what you should be doing! But to succeed, you definitely must introduce new overhead to make things perfectly incomplete.
You must have a knowledgeable Scrum Master and a proficient Product Owner. You must master Scrum, otherwise it’s going to fail. But even when you do Scrum perfectly, it’s still perfectly incomplete, so whatever doesn’t work is still your fault.
Are you still able to follow? Yes, it’s that absurd.
Even though it's pretty evident that Scrum often comes with problems, such as:
Sprints seem to put people on the wrong foot as if we should rush to complete everything in the Sprint. If you're inspecting and adapting, Sprinting isn't the right image we should be evoking.
Lots of talk about how to do better Scrum, while Scrum should be in the background.
The Sprint Review is mainly misunderstood, as the label is confusingly similar to Sprint Retrospective, and people mistakenly believe it's a Sprint Demo. The label sucks and is too similar to Sprint Retrospective. Plus, you’re not reviewing the Sprint, so the focus is already wrong.
The Product Owner rarely owns anything and mostly accepts requests from the Product Manager or other stakeholders.
There is a big gap between Scrum's theory and practice, and entertaining the notion that maybe the way Scrum is explained and that the chosen Scrum terminology is part of the problem is instantly rejected. There’s too much at stake with all the money that’s tied to those labels.
I want to stress that I could be wrong about everything I’m writing in this article, but that doesn’t matter. We should still be able to have an open discussion about it instead of immediately rejecting it because Scrum has a ‘Get Out of Jail Free’ card built in.
As I’ve written before:
“If failure cannot be attributed to Scrum, then neither can success.”
If Scrum is perfectly incomplete, then Scrum Guide adherence is not the biggest problem you should be worried about.
Is your way of working ultimately producing the results you want? Whether it adheres to the Scrum Guide or not is of secondary importance, as it’s written by humans who are as fallible as you and me. Adhering to the rules of Scrum is never the point but what that compliance is supposed to help you to achieve.
Scrum expects you to supplement Scrum. If you don’t supplement Scrum, it’s guaranteed to fail, no matter how perfect your Scrum is.
Supplementing Scrum the right way is what we should be worrying about the most, not perfect Scrum.