Skip to main content

Feel free to change Scrum!

One standard bit of advice from Scrum Trainers and Coaches is "Don't change Scrum!" They give this advice because,
  1. There is a natural tendency when adopting something new to want to change it, i.e. to make it "yours."
  2. Scrum is designed to detect problems, including deep seated problems, quickly and mercilessly.
  3. Scrum pushes people and organizations out of their comfort zone. Rather than face the problems, it is often easier to try to change Scrum than to confront the problems Scrum has detected.
Combine these factors, and you can quickly defeat the purpose of Scrum, which is to identify and eliminate impedments to success (in Lean, this is referred to as "Waste") as quickly as possible.

So when Silvan Mühlemann, CTO of, proposed a talk for the Scrum Breakfast "Adapt Scrum to your needs!" I thought "Oh my! can I allow this sacrilege to occur on my watch?" So I got him to put a question mark in the title, closed my eyes, and off we went.

When Silvan got started, he didn't believe that Scrum would work in his company, so he changed it. Pretty dramatically. For instance, time boxes yes, fixed length iterations no. At the beginning of his talk, I wondered if we could even call his process Scrum. He definitely broke a lot of rules of Scrum. But he stayed true to inspect and adapt. That process brought him closer to Scrum by the book (adding retrospectives, daily scrums, ready to try again with fixed length iterations, etc).

The talk was a real eye opener. If your top management gets the principles of Scrum, the practices are less of an issue. Just be true to "inspect and adapt." If they don't, well, it can be tough.

Oh and BTW - every team which does Scrum changes their process. Why? Because they do a retrospective every Sprint to improve that process. And each time, that process should change a little bit. Add up those changes over a year or two, and the differences can be quite substantial (..and probably make your Scrum rather different that what you would find in the book).

Silvan's presentation is (finally) on line: Adapt Scrum To Your Needs, by Silvan Mühlemann (in German).

[Update 30-Aug] Lest their be confusion: As a coach and trainer, I still tell teams not to change Scrum, especially not before they have really understood Scrum. Changing Scrum is usually dysfunctional and usually gets you into trouble. What is the worst ways to change Scrum? Hmm. Combining the role of ScrumMaster and ProductOwner is probably top on my list. You risk getting a demanding customer with no one to protect the team.


Daniel Marbach said…
Hello Peter,
I have been thinking about this topic also. But calling it scrum is in my point of view really against the ideas of the founders. Kent probably wouldn't like this. Also really dangerous is, that some lazy people somehow find a way to "adapt" scrum so that practically they almost don't change their behaviors and then say to customers: "We are doing scrum!" I say: "No you don't". For me the important message is to stick to scrum and it's principles as long as the process is understood and lived by the employees and then change and adapt it to your need and call yourself "agile people".

Peter said…
Hi Daniel,

In general, I agree with you. And speaking as a coach and trainer who has seen a lot of bad Scrum, I give the same advice.

At the Breakfast, I asked the group, "Is Silvan doing Scrum?" To my surprise, the majority of the audience, including at least one CSP, said yes. Why? Because he was applying the principles.

Most people don't get principles until they have really internalized the practices. Management, especially top management is often the last to get it.

I have also seen a lot of arguments along the lines of "My Scrum is better than your Scrum," i.e. people arguing about details of the practice. I now ask, are you applying the principles? And if the answer is yes, that's when I back off on being fussy about the practices.

Unknown said…
IMHO adapting Scrum, telling the customers "We do Scrum" and then failing is certainly against the idea of Scrum.

In our special case, we were able to double the productivity thanks to Scrum (or - if you prefer - the "method inspired by Scrum"). So I see no problem in giving Scrum the credit for this process improvement.

Nevertheless, I am sure this only worked in our company because the settings were ideal:

* Young team (Average age of 26)
* Small team (6 developers)
* mainly internal clients
* "Scrum master" is part of the company management

I certainly would not recommend doing it our way if the settings were different than ours.

Peter said…
Hi Silvan,

I think you've made a good point about the young company.

Young children learn differently and faster than adults. Young adults faster than older adults (usually ;-) ). I think there is something similar at work with young companies. Something about the patterns not being too rigidly entrenched.

If I think someone deeply understands the principles, I don't have problems with their changing the practices, even the 'holy ones.' Unfortunately this state occurs so infrequently in nature...

Urs Enzler said…
Feel free to change Scrum!?!?

Yes and no.
Scrum is a framework. And like any other framework (e.g. the .NET framework) you cannot build something working with it alone. However, there are two ways of "changing" a framework.
Either you add parts to it or you replace existing things with something new.

Regarding Scrum, I consider adding stuff (like additional meetings, additional practices, ...) a need. Only these added details get you running in your situation.
BUT, removing or exchanging a fundamental part of Scrum will lead you on a dangerous way.
Scrum works because there are very few simple rules to follow, and all are important.

Therefore, adapt Scrum to your needs but don't change it.

Further reading can be found when googleing for "Scrum but"
Peter said…
Hi Urs,

Couldn't agree more. Most people who change Scrum get themselves into trouble.

BTW - I ran the first poll on the Nokia test und posted the results under "Is anybody really doing Scrum?" 3/4 of the teams were not, and protecting the team members from management was the biggest failing.

My understanding is that Jeff Sutherland launched the Scrum But discussion with this presentation at Agile 2008. You'll notice which study he quoted.

Doug said…
We often need to change things or reinvent them ourselves. That is probably the nature of understanding and taking ownership for something. If someone does my thinking for me I will never really understand the "why" behind it. I keep the scrum framework clean and light so that I can remember where I have been. I restart my head when it gets confused.

For new folks out of the gate that are not used to a strong empirical thought process , my advice is to use "Scrum" as is and avoid modification, go slow. The place you will get in trouble the quickest is in the area of organizational change. Your desire to run through all of the issues you see will be a strong temptation that will get you into trouble fast. People don't change that fast(self included) and neither do big organizations! give yourself and them time to learn from the Scrum Framework. It is never done teaching you.
- Doug Shimp

Have I modified it? Sure! I also have wished I hadn't :)
Peter said…
Hi Doug,

I like your concept of "sense of ownership".

Last week, I stumbled upon Ken Schawaber's original OOPSLA paper. I barely recognized Scrum.

Scrum has evolved and continues to do so. But of course, we only read about the successful mutations.



Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…