Is it okay to change Scrum?

Is it okay to change Scrum? This question can be a hot potato! When we are honest, there are two correct answers: 1. No. 2. Of course! The more interesting questions are: What are you doing differently? Is it okay? Read on for guidance about good changes to your Scrum.

Scrum is defined by the Scrum Guide, and nobody but its authors can change that definition. When the Guide says that Scrum is immutable, I think they mean that you can’t redefine Scrum and still call the result Scrum. The creators of forks like ScrumXP or ScrumBOK ought to come up with new names for their products!

What about how you do Scrum? Must you your implementation be perfect to call it Scrum? Is it even possible to do Scrum “perfectly” by the book?

Personally, I do not believe that is possible. In theory, theory and practice are the same, but in practice, they are not. Much of the 2020 Scrum Guide is about making the guidance more abstract and generally applicable, while leaving open the details of how to do it.

Especially at the beginning, you do the best you can; accept that you are going to learn and improve. Ideally, over time your Scrum gets better, and your team’s effectiveness improves. It’s all about inspect and adapt!

As you move forward, you might want to deviate from Scrum. Some team members might not like doing the Daily Scrum. Others might want to pair or swarm. Are these changes good idea or not?

To evaluate a change, I suggest looking at the reason for making the change, and the probable outcome of the change.

Reasons

Why are you making the change? If you are making the change by agreement of the entire Scrum team, and you are doing it to improve your collective effectiveness, then it is probably a beneficial change. If you are compensating and absent Product Owner, overbearing Scrum Master, of poor event facilitation, the change is more questionable and probably represents are return to the status quo.

Expected Outcomes

What benefit do you expect from the change? If you expect faster feedback or to produce tangible results sooner, these are probably good changes. If you are compensating some dysfunction, e.g. a Product Owner who doesn’t show up for Sprint Planning, or Developers who cannot produce “Done” functionality every sprint, then it’s questionable whether changing Scrum will help.

I like to think of Scrum as a working agreement among the members of the Scrum Team and its Stakeholders. I wish working agreements were a fully valued thing in Scrum because they are a powerful from of commitment, and they point the way to further improvement from the reference implementation.

The core principle of Scrum is Inspect and Adapt. If you are unsure whether a change is a good idea, try it for Sprint. Is it an improvement? Great, keep doing it! If not, go back to what you were doing before, or try something else.