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. Rolf says:

    “The test of a first rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.” (F. Scott Fitzgerald)

    Very nice essay about a central Scrum dilemma. Only wish you had revealed the secret how a Shu apprentice may recognize he’s still an apprentice, a Ha journeyman that he’s become a journeyman and a Ri master that he’s finally become a master – plus, when it’s time to start the journey again! ;-)

  2. Hans-Peter Korn says:

    Hier auch die in XING laufende Diskussion:


    Hans-Peter Korn: Wieder so eine wenig hilfreiche Dogmatik: 1.: Scrum ist nur dann Scrum, wenn es 1:1 dem Scrum Guide entspricht. OK – das ist in Ordnung – siehe z.B. auch “Schach” ABER: 2.: Und nur dieses “echte” Scrum funktioniert problemlos. FALSCH!! Es funktioniert ALLES, was zur jeweiligen Situation passt. Und umgekehrt: Scrum kann auch unpassend sein.


    RFK: Der Post sagt nirgendwo, dass “nur dieses echte Scrum” funktioniert. Ganz im Gegenteil.


    Hans-Peter Korn: Ich zitiere: “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.” Also: Es wird behauptet, dass nur das “echte” Scrum problemlos funktioniert. Sehr oft erzeugt Scrum aber Probleme – z.B. wegen der in grossen Firmen unrealistischen Rolle des Scrum PO – die gar keine sind. Ein falsch anzeigendes Thermometer sollte man aber besser wegwerfen.


    RFK: Im weiteren sagt der Autor: “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.”


    Hans-Peter Korn: “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.” … JA, aber OHNE die Elemente oder das Framework zu verändern. So wie das Nachdenken über ein Schachspiel nicht dazu genutzt werden darf, die Schachregeln zu ändern.


    Bernd Schiffer: Hans-Peter, mit “… as the framework with it’s essential elements itself.” meine ich genau die Veränderung des Frameworks Scrum. Essentielle Elemente sind die Meetings, Artefakte, Rollen und Regeln nach Scrum Guide/Core Scrum.


    Hans-Peter Korn: Ok – die essentiellen Elemente zu verändern damit es besser zur spezifischen Situation passt ist legitim und auch ein übliches Vorgehen der Organisationsgestaltung. Derartiges als ein “Scrum But” abzuqualifizieren steht IHHO im Widerspruch zur professionellen OE-Arbeit. Es dann eben schlichtweg kein Scrum sondern etwas anderes, besser Passendes. Und so etwas wie ein den individuellen Interpretationen unterliegendes “Core Scrum” unterstütze ich nicht. Scrum ist das in den 17 Seiten des Scrum Guide Beschriebene. Punkt. Ken Schwaber ist hier übrigens recht flexibel. In schreibt er: “Scrum can be replaced or superseded by anything that also supports its underlying principles: 1. Self-organization 2. Bottom-up intelligence 3. Empiricism 4. Transparency I welcome anyone who comes up with the next great process, one that does all of the above even better than Scrum.” Wobei er ganz oben schreibt: “(scrum) is barely a process, only a framework” Und: Auch hier an einen “next great process” glaubt, den es für stets spezifische komplexe soziale Handlungssysteme eben NICHT gibt.

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

  4. @AgileRenee says:

    I have been probably one of the longer running candidates for being a Scrumbut user. Back when I started Agile 11 years ago, the rulebook was slightly different – retrospectives were part of XP and not Scrum and many blended XP and Scrum effortlessly without issues. This time could be described better as doing ScrumAnd. However I also spent a lot of time experimenting, even whilst myself and my teams were in the “shu” phase.

    I was an early breaker of the “must be four week Sprints” rule, trying three, two and one weekly Sprints. I eventually settled on two weekly Sprints for large (ten person) teams and weekly for smaller teams.

    In smaller teams of 2-3 people I experimented with part time Product Owners – people who co-located with the team for a few hours, but were otherwise contactable at any point in time by phone.

    I played with having taskcards, removing Sprint Burndowns and replacing it with stronger visual observation as a marker for Sprint goal failure risk.

    Release Burn Downs became Release Burn Ups. The relative worth of a Scrum Master full time versus part time was played with.

    I did all this because in those early adoption days guidelines, blogs and books were very limited. I did this because the manifesto said “Individuals and interactions over processes and tools”. I saw Scrum as a process but it did not govern or supercede the manifesto and so I played with the rules hoping to test under what conditions ‘Individuals and interactions’ was better realised and what size of Sprint lengths allowed more effective delivery of working software.

    If Lean Startup had been around in those days, not only me, but many of us would have been seen to be setting hypotheses, building, measuring the effectiveness of the change in process because we certainly needed to learn what worked and what didn’t.

    I believe, to an extent, that Shu-Ha-Ri is applicable, but there is no clear point to me, nor do I think there should ever be a point when experimentation is not allowed. What early adopters have learnt are the conditions and root causes why certain elements should and should not be done. I only think it appropriate that Ri experimenters delve into the unknown with their eyes wide open to the risks that the previous experimenters have found. This is where the learning can be daunting because this is where the rulebook changes into guidelines and there is a lot of information out there to sift through.

    I have seen a team successfully deliver a project with no product owner using a combination of Scrum and Learn Startup. By a strict classification this would be considered Scrumbut, however it was a very successful project (probably more than many others I know because we could prove benefits realisation rapidly and the customer was ever present in the data).

    I have seen successful teams have a board of Product Owners. In fact, I am a member of such a board right now. It isn’t detrimental. Prior to the beginning of each Daily Scrum, as a board of Product Owners we collectively decide on priority. The card colour denotes the Product Owner and if the team has queries they know easily who to go to for immediate feedback. Problems with process are only problems if you let them be.

    I see teams follow Scrum by the letter and fail – the wrong person was the product owner, cards weren’t broken down enough, the list could be quite exhaustive.

    There is always risk in experimenting, but in saying “shu” learners should only go by the rulebook, without encouraging any critical thinking, is only further encouraging the lack of movement into “ha”. When we (as trainers) teach “shu” I believe we should have a responsibility to seed “ha”. It isn’t just about “do x, y, z”, it is “x works best when …”, “x is hard to do when …”, “you may want to consider to also do w when you do x”, in essence, it is the:

    what (approach)
    why (purpose/intent)
    who (is involved and to what extent, RACI is a good model for this)
    when (how often, how does the time impact other elements) and
    how (does it feel when it is working right versus working poorly)
    We need to teach people how to think, learn and critically assess, not just give solutions. We need to stop telling them off for experimenting. If that had happened in the early days of Scrum we may have never learned of the value of shorter Sprints and of the hundreds of useful tips, techniques and tricks that we apply each day.

    Scrumbut is and has always been a terrible name for deviating from the standard definition. You might argue that what I do is Scrumbut. I would say I do Agile –

    For my team and my organisation, I endeavor to improve the cost-effective delivery of value to customers through the establishment of a collaborative, safe, supportive and ever positively evolving environment.

    Shouldn’t that be the intent of Scrum too?

  5. Vin D'Amico says:

    I agree that many teams abuse Scrum (and other agile approaches) by adapting it to their perceived needs. That’s how we often end up with scrum-fall – it’s waterfall with a few Scrum practices woven in.

    However, we need to avoid Scrum dogma. If we are too strict and overly rigid in our Scrum implementations, how will Scrum evolve? How will we make it better? We must remain open to new ideas that preserve the essence of being agile.

    Scrum is not perfect – not even close. It’s a framework for delivering better software. Rather than adapt Scrum to their needs, I encourage teams to adapt their needs to Scrum. They often find that their needs aren’t as important as they thought. Thanks for sharing!

Leave a Reply

Your email address will not be published. Required fields are marked *