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 tilllate.com, 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.

Comments

LOBOMINATOR 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".

Daniel
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.

Cheers,
Peter
silvan 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.

Silvan
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...

Cheers,
Peter
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.

Cheers,
Peter
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
http://doug-shimp.net

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.

Cheers,

Peter

Popular posts from this blog

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …