Scrum Breakfast in Bern: Introducing Change
26-08-2009Gimme back my waterfall!
29-08-2009One standard bit of advice from Scrum Trainers and Coaches is “Don’t change Scrum!” They give this advice because,
- There is a natural tendency when adopting something new to want to change it, i.e. to make it “yours.”
- Scrum is designed to detect problems, including deep seated problems, quickly and mercilessly.
- 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.
8 Comments
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
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
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
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
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"
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
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 🙂
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