As a scrum master and coach, I see the phrase “doing scrum wrong” thrown around a lot. Scrum practitioners often worry about making missteps, while detractors lambast scrum as being unrealistic and too rigid for how “the real world works.” In both cases, scrum is cast as a magical route through a maze of death traps (i.e. any project ever). Deviate from this hallowed path and you will surely wind up impaled at the bottom of a spike pit or crushed by a surprisingly spherical boulder.
I once heard a wonderful analogy likening scrum to basketball. At a basic level, basketball doesn’t have a lot of rules. Two teams of five compete, only being able to traverse the court by dribbling the ball without pause or passing. Teams score by shooting the ball into the opposing team’s hoop. Generally speaking, that’s it.
So with those rules in mind, why do some teams win and some lose? It’s not all skill. Just like how a “10x developer” does not guarantee instant success on a project, having one of the most talented players on your squad doesn’t make an NBA championship a shoo-in. It’s often less about the players (though talent helps) and more about how teams operate within those foundational rules.
Rebel scrum
Scrum is a lot less controlling and complicated than people think. When you get right down to it, you are “practicing scrum” if you stick to the foundational 3-5-3: Scrum has 3 roles, 5 rituals, and 3 artifacts. That’s it. Everything else is just finesse.
So what happens when the rules are broken? How are anti-scrummers punished? Well, they’re not. Scrum is a basic framework, not a morality play. There is no referee on a scrum team (no scrum-pire, if you will). The scrum master is there to educate the team about scrum, not rigidly and blindly enforce its doctrine no matter what.
Take, for example, a simple scrum ritual: the daily standup. Originating in the military, each morning team members would share what they would likely work on that day as well as what they accomplished the day before. If you work in a distributed company like me, your teams won’t be in the same time zones, so when the heck do you have the standup? I guess scrum just doesn’t work in this instance, said some doubting Mufasa.
Scrum is less about the when and more about the why. Why do we have daily standups? It’s not to get a status report, for one. Rather, it’s to communicate and share data, while ensuring no one is spinning their wheels because they are too intimidated to ask for help. Tweak expectations and have the team cover what was done before the standup and what will be done between now and the next standup. Or, pare it down even more and focus solely on blockers people have and identifying who can remove these. As a scrum master, getting a true understanding of the team’s confidence in completing the sprint’s commitments is world’s more valuable than some dry status update. The worst thing a Scrum Master can do is resolutely impose the “what” of scrum without a clear vision of its “why.” Once you really understand the why, you can manipulate the scrum framework to best support you and your team.
No one works in a vacuum (except astronauts) so there will be constant decisions a scrum team has to make while leveraging the beneficial whys of agile. Scrum is much less about adhering to the rules and more about rethinking its basic structure to create the most efficient, productive, and happy (yes, happy!) work environment for the team.