Alter the System, Alter the Outcome: The Danger of Changing Scrum

Scrum skeptics and some newcomers often balk at the idea that Scrum can’t be changed. One challenge, often issued as a “gotcha” question, is that Scrum’s mandate that it cannot be changed violates the first value of the Agile Manifesto. Isn’t saying that you can’t change Scrum valuing a process over individuals and interactions?

The short answer is no, it doesn’t—and here’s why Scrum should be used as intended.

Cherry-Picking Scrum Isn’t Scrum

First, let’s look at what the Scrum Guide actually says about changing Scrum:

Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

It very specifically says you can implement some components of Scrum without implementing the whole thing. You’re free to omit an event or change the rules. The Guide merely points out that making those changes means you’re not practicing Scrum. It’s no different than saying that if you allow any player to pick up a soccer ball and run with it, you’re not actually playing soccer.

Obviously, you can change Scrum—no one is going to stop you. But it isn’t Scrum anymore if you do, and why that distinction is critical points to some important reasons why you shouldn’t change Scrum.

It’s a distinction that matters because, like all agile frameworks, Scrum is a complex, adaptive system that has evolved over time so that it produces a specific output: working product, thoroughly tested and potentially releasable. If you change or omit a component, you’ll likely change the outcome in undesirable ways.

Break the Rules in a Meaningful Way

When I was in junior high school, my English teacher hit me with the old bromide: You have to know the rules of English to break the rules. And I, smart aleck that I was and still am, replied, “I can break the rules good. See? I just did.” And she said, “But can you break them in a meaningful way?”

Her point proves valid for Scrum, as well. You can break the rules, but can you do it in such a way that the outcome is meaningful? Can you break the rules of Scrum and still produce working product on a regular basis, in a short time frame?

If you can, go for it. If you’re not there yet, you’ll do yourself, your team and your organization a favor by implementing Scrum as it is designed and using it to become expert at delivering “Done” software. The purpose is not “to get good at Scrum” but “to get good at delivering working software.” Then, if you feel that a component should be changed or omitted, you can make an informed decision, run an experiment, and see if the change is effective.

In my next blog, I’ll dive into Daily Scrums, explain why people tend to change these Scrum events, and highlight ways to correct the problem. In the meantime, check out our agile and Scrum blog for other helpful tips and advice.