One standard bit of advice from Scrum Trainers and Coaches is “Don’t change Scrum!” They give this advice because,
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.