Scrum's Built-in 'Get Out of Jail Free Card' Against Criticism
When Scrum Doesn't Work, It's Always Your Fault
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.
My impression and experience working in many "classically" or Scrum-driven projects: you either have a team that works, or you don't. Teams mostly work because people communicate well, respect each other, have the necessary skills required for their job and form a unit with a shared sense of goals. Of course, this list is not exhaustive and external factors are important as well, but I'll leave those out of the equation. On the other hand, there are teams that don't work well together, because they're missing one or more of these crucial ingredients. But, and that's my key learning, Scrum needs all these qualities as well, else it will fail. If a project is lucky enough to have a very good Scrum master and product owner(s), they might be able to help a team form through various means.
So... you have this "mythical", but totally incomplete methodology that almost totally depends on factors it can't create itself: what's its purpose then?
There's another crucial factor: is a team really allowed to go all-in on Scrum, meaning it has the support of the rest of the company to provide them with what they need in time and quality? More often than not, deadlines and budget are still fixed (which, from a company's point of view, is perfectly valid), but this removes one of the most important pillars Scrum is based on.
What was the reason for Scrum's success then? Well, I'd argue that it was driven by management, because they learned what happens if you let a team go "black box", missing dead lines, quality, etc., so they got totally excited by the promise of constant, visible delivery. Fair enough. Also, it's a nice, fashionable way of controlling and tracking people, that veils itself as transparency. We don't need leadership, it all falls into place by itself by some democratic process. Many people don't work that way, that's a reality, whether we like it or not. But, and this is one of my most crucial reasons to resent the Scrum hoax: pressure of constant delivery plus chunking tasks into bite-size tasks strongly disadvantages complex, foundational and cross-concern work. Error handling or security (just to name two topics)? Nah, we don't need it now, let's get stuff done! Except: this is all needed! I like to compare it with building a house: nobody would start working on the cosy bed room on the second floor before the foundation is done. Can't build a bathroom without pipes being installed before. How did we think we could build software this way? Of course, all of this can work with Scrum, as it does not prevent good work from happening. But: you need the right people in the right setting. And then you're back to square one, see above.
One last thing: people are not stupid. Once they realize that they're not in a real Scrum setting, they learn how to cope with the situation. Rituals degenerate into meaningless bla bla, story points are not story points anymore, velocity tracking is not perceived as a chance to improve, but surveillance, etc.
For me, the quality of a software product is more determined by people than by tools or methodologies, always was, always will be.
I've only been on the side of rocky scrum situations for my entire career. I have yet to come across a single person that was like, "Mike. Scrum following all the rules is the best!" Many of us have adjusted (aka lowered to rock bottom) our expectations with it.