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