Blasphemy! They Call It Scrum!

Would you still call it a tulip?
Would you still call it a tulip?

Assume a perfect Scrum implementation. All artefacts, all meetings, all roles, and all rules are in place. If you were changing only one of the essential elements of Scrum, would you still call the remainder Scrum?

No. We call the remainder ScrumBut.

While doing Scrum, practitioners come across problems which prevents them to implement a specific Scrum element. For example, …

  • … they might have a problem doing a Daily Scrum every day, so they do it only once a week.
  • … they don’t think retrospectives are necessary, so instead they skip this meeting.
  • … they have a problem finding s single person to be a product owner for a team, so they replace the PO role with a group of managers on a board.

This pattern is called ScrumBut:

“We use Scrum, but {superficial reason}, so {bad workaround}.”

According to this pattern, the first of the aforementioned problems can be rephrased as: “We use Scrum, but we have problems getting all team members together every day, so we do it only once a week.

ScrumBut is considered to be bad. I agree. ScrumBut means avoiding problems rather than solving them. It’s like smashing the thermometer just because you discovered a fever.

You need experience to identify ScrumButs. A novice runs into problems all the time when he’s confronted with new things. Failures are part of learning. Most failures occur because the novice used Scrum as it wasn’t meant to be (Weekly Scrum instead of Daily Scrum). He thinks the cause for the problem lies in the limitation of Scrum, not in his limitation to use Scrum. I can’t remember a single case I’ve seen during a novice’s first steps with Scrum, where Scrum didn’t discover a dysfunction in the novice’s environment rather than a novice discovered a dysfunction in Scrum.

My advice for Scrum novices: do Scrum by the book. There’s Ken Schwaber’s and Jeff Sutherland’s Scrum Guide, and there’s the Scrum Alliance’s Core Scrum statement. Both guides cover the essential elements of Scrum. Pick a guide. Do what it says. Be strict and don’t compromise. When you’re in doubt whether you’ve got it wrong or the guide, be assured that it’s you. Trust the guide. If you don’t understand the guide or you don’t know how to do what the guide prescribes, ask someone with experience.

Back to the question whether the remainder is still called Scrum when you change an essential element of Scrum. With regard to ScrumButs and Scrum done by novices, the answer is: No, you can’t call it Scrum if you’re not doing it by the book.

Yes, we call the remainder Scrum.

A principle of Scrum (and also Agile) is “inspect and adapt“. It means to apply a factor, observe its behaviour, and change according to the observation with an expected improvement. There are 2 inspect-and-adapt elements in Scrum, the Sprint Retrospective to inspect and adapt the process, and the Sprint Review to inspect and adapt the product.

During a retrospective, the team observes the behaviour of the things they applied before the retrospective. The outcome of a retrospective is one or more actions about what to change until the next retrospective. Actions are directed to discourage bad behaviour and to encourage good behaviour. For instance, the team decided to replace one factor (“Daily Scrum at 9am”), where the team observed a behaviour (“long sleepers are grumpy”), with another factor (“Daily Scrum at 11:30am”) with an expected outcome (“long sleepers are pleasant”).

What would happen if one of the actions from a retrospective are directed to change an essential element of Scrum?

The answer for novices is: Don’t! You don’t know what you’re messing with. All kinds of things can break loose. Stick to the book.

Core Scrum and Scrum Guide are very clear about this:

“The Scrum Team improves its own process, always remaining within the Scrum framework.” — Core Scrum

“Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.” — Scrum Guide

The message one can read here is: Don’t change Scrum! Danger! Don’t saw off the branch you’re sitting on (German proverb)! You might harm yourself!

I’m fine with that, and this is also what I teach in my classes – to novices. I’m not cool telling this to experienced people, and I don’t think that this is or should be part of Scrum’s DNA.

Shu Ha Ri

Shu Ha Ri
Shu Ha Ri

Shuhari is a model (Japanese and martial arts background) which describes 3 stages of learning to mastery:

  • Shu: 1st stage. Novice. Learn the rules and stick to them. No deviation.
  • Ha: 2nd stage. Expert. Break the rules. Innovate.
  • Ri: 3rd stage. Master. No need for rules (not even for breaking them). Seeing the matrix.

Alistair Cockburn made this model popular in the Agile community, and I find Shu Ha Ri very helpful, especially in this context. (You might also want to check out the Dreyfus model of skill acquisition; it leads me to the same conclusions.)

Both, Scrum Guide and Core Scrum, are addressed to students at Shu level. Advice to do Scrum by the book is addressed to students at Shu level. A statement like “No, you can’t call it Scrum if you’re not doing it by the book.” is addressed to students at Shu level.

Scrum has plenty to offer for students at Shu level. But what about the students at Ha level? Those who already learned the rules and obeyed them, who lived by the rules a long time, and who internalized the essence of Scrum. Those who break the rules and who want to innovate.

It’s just not enough to come up with the same statement again, that if the Ha team doesn’t follow Scrum by the book strictly, they are not doing Scrum anymore. If a Ha team is so innovative to find a better way to do Daily Scrums, to come up with an alternative for the PO, to replace a Sprint Retrospectives with something better, should they then lose their seal of approval called Scrum? The Ha team changes a single essential element knowingly, aware of all the consequences, and they do succeed with this change, and all they get is thrown “You’re not doing Scrum anymore!” in their Ha faces? That’s like breaking a Ha fly on a ScrumBut wheel.

I refuse to follow that path of dogmatism. Scrum is not a belief system, where a dogma is “…established as undoubtedly in truth.” The advice for Shu practitioners to do Scrum by the book is different from preaching a dogma, since there is (or should be) awareness that Shu is only the 1st stage, and that on other stages one will be encouraged to do Scrum beyond the book. In this sense, every element of and within Scrum should be examinable via inspect and adapt, i.e. elements of process and product covered by the Scrum framework as well as the framework with it’s essential elements itself.

(Btw: I have the ignorance of the unimaginative until here *finger hovering over my head*. Only because you can’t think of a good replacement for a PO, or a Daily Scrum, or you name it, does not mean that there is no such thing as a good replacement for these elements. Be aware of unknown knowns, i.e. things that exist and you are not aware of. For my part, I do think that for every Scrum element there is a better replacement out there which I’m not aware of yet. Please try to take in this point of view. It’s very relaxing, widens your horizon, and doesn’t let you startle every time a good replacement actually crosses your way.)

Good deviation

How do you distinguish a bad deviation (ScrumBut) from a good deviation? A deviation occurs when an essential Scrum element is replaced by a new element which alters the Scrum framework. The deviation is bad, when one or more of the intentions behind the original element are not met anymore. For example, replacing a single person PO by a PO board is a bad deviation, because one of the intentions behind the original element (fast decision making) are not met anymore. An example for a good deviation is the replacement of the Daily Scrum with a standup every 1.5 hours, because all of the intentions behind the original element are still (and even better!) met with the use of the new element.

Scrum itself had some good deviations in its history. The last good deviation is only about 2 years old, when two essential elements of Scrum were changed. The prioritised product backlog was replaced by an ordered product backlog, and the term “commitment” regarding the work selected for a sprint was ditched in favour of the term “forecast“. Nobody could’ve ever come up with these improvements if he had not left the Scrum path for a while to wander in the fruitful valley of deviation.

Dogma is the killer of innovation. To improve Scrum you need to have good deviations. Without questioning the essential parts of Scrum, Scrum will end up in a dead end. Teaching “inspect and adapt” without eating you’re own dog food is hypocritical.

Back to the question again: Is it still called Scrum when you change an essential element of Scrum? For a Ha stage Scrum practitioner my answer is: Yes, you’re still doing Scrum if you change an essential element of Scrum.

Why care?

If there was only a single team using Scrum, it would make no difference what name they call it they do. Success tells them if they’re doing fine. Names are not important for a single team.

But there are many teams out there, and they want to talk about the things they do, to learn from each other. Names and what they refer to are important for communication. If you have the same name for different things, you will have problems to learn.

If Scrum refers to too many things, it becomes blurred and less helpful as a framework and meme set, and discussions about Scrum would become even more difficult. The definition of what Scrum is has to be very precise, and the creators of Core Scrum and the Scrum Guide did a great job so far in shaping the definition of Scrum.

Despite the importance of a definition of Scrum, I fear the exclusion of innovators from the Scrum community and the deceleration of innovation within the Scrum community. I’ve had my share of people running around with their ScrumBut hammer, seeing every deviation, bad and good, as a nail. Innovations will die when one is afraid of the next “That’s not Scrum!” shit storm. It’s like a disinvitation from the community.

That’s why I care. I want Scrum to inspect and adapt, and that’s just harder without innovators or innovations. The Scrum community should embrace the innovators and every innovation they bring along.

Natural border

When you can change essential Scrum elements, and still be able to call it Scrum, where does it stop? You could end up with a totally different framework, or even better, you could come up with the next big thing after Scrum, but nobody would know because you’d still call it Scrum. You would refer to different things with the same name, and that would screw up a lot. If you change a lot, you’d come up with something different, and there’s little value in calling something completely different with the same name.

Scrum was compared to Chess by Ken Schwaber: “Scrum is like chess. You either play it as its rules state, or you don’t.” Chess itself was the initial spark for a huge amount of chess variants. A chess variant is a game which “… related to, inspired by, or similar enough to the game we call Chess today.” This means, compared to Scrum: if a Scrum practitioner comes up with a totally different software development framework, which is related to, inspired by, or similar enough to the software development game we call Chess today, she shouldn’t call it Scrum.

On the other hand, in the so called Fast Chess each player has very limited play time. With this variant, the game behaves very differently from the original Chess, yet only one (but essential) element is changed. Changing an essential Chess element still allowed the game to be called Chess.

Joshua Kerievsky and his colleagues at Industrial Logic had so much good deviation with their Extreme Programming implementation, that they called the result Industrial XP. Kent Beck and his colleagues improved their first version of Extreme Programming, and 6 years later he wrote a 2nd version of his classical book “Extreme Programming Explained: Embrace Change”. It was so different from the 1st version, that people refer to it as a 2nd volume (XPec2e), a new book, rather than a 2nd version of the original book. Even though that both, Industrial XP and XPec2e, have different essential elements than the original XP, they are both still called Extreme Programming. Types of classes in programming and ontology comes to mind.

I have no doubt that once you are on the Ha stage, you’d notice a) that you’ve changed an essential Scrum element and b) when you’ve changed so much of the Scrum framework that you’d need to call it differently. A Ha stage Scrum practitioner would be aware of the natural border.

Scrum as a Basis

I like the perspective that Scrum is just the beginning. Rowan Bunning wrote that “Scrum is a management innovation framework to which savvy leaders add further innovations.Scrum as a catalyst for innovation, a starting point for further exploration (cf. Moving beyond Scrum)? Great!

(Btw: Ken Schwaber calls it Scrum And (“At the most basic level, the question is: Are you using Scrum or not … . Scrum And is then a path of continuous improvement in software development beyond the basic use of Scrum.“); Scrum Alliance calls it GASPs, General Accepted Scrum Practices.)


The answer to the question, whether the remainder is still called Scrum when you change an essential element of Scrum, depends on the receiver:

  • Shu stage Scrum practitioners: No, you can’t call it Scrum if you’re not doing Scrum by the book. If you’re not doing Scrum by the book, chances are very high that you’re not doing Scrum.
  • Ha stage Scrum practitioners: Yes, you’re still doing Scrum if you change an essential element of Scrum. Stop calling it Scrum and name the new method once it emerges.

For a great Twitter discussion, thank you Craig Brown, Renee Troughton, Neil Killick, Chris Chan, Rowan Bunning, Alan Dayley, Maurice le Rutte, Jens Meydam, Woody Zuill, Jason Yip, Michael Rembach, Matthew Hodgson, George Dinwiddie, David Allsopp, Ilan Goldstein, Stefan Roock, and Kevin Austin.

This entry was posted in General and tagged , , . Bookmark the permalink.

About Bernd Schiffer

Bernd Schiffer is consultant, trainer and coach for Agile Software Development in Melbourne, Australia. Learn more about him on his personal homepage, have a look at his company Bold Mover, or contact him on Twitter, Google+, Facebook, XING or LinkedIn.

8 Responses to Blasphemy! They Call It Scrum!

  1. Pingback: Scrum intentions, Scrumbut, Scrumand and Shu-Ha-Ri | The Agile Forest

Leave a Reply

Your email address will not be published.