I first heard the term, Scrumbut, introduced by Mike Cohn at a Denver Agile User Group meeting. The term is used to describe people who might say, “We follow Scrum but … we don’t do stand-up meetings” or “We follow Scrum but … we have 3 month iterations” or “We follow Scrum but … [some other exception].”
This got me thinking a lot about the “rules” of Scrum, and wondering which rules were strict and which rules (if any) were flexible. It seemed a little overly-prescriptive to me for a methodology that touts “adaptability” to not allow some flexibility.
I explored this issue at my last Boulder Agile User Group meeting and wrote about it in, Daily Scrum meetings: Must we really stand up?
Curious about how agile experts felt about this, I read two perspectives on ScrumButs, one by Jurgen Appelo titled: ScrumButs are the best part of Scrum and another by Cory Foy: ScrumButs are the downfall of agile. Both make some very interesting points. Appelo says:
When you believe that Scrum teams are self-organizing systems (which I do, and I know Ken Schwaber does too), then you must accept that optimal behavior of a team cannot be predicted.
Foy counters with:
When you are experienced, you know where to take shortcuts, where things won’t bite you. But when you don’t – and I’d venture to say that’s where a majority of Scrum people are – taking shortcuts isn’t just detrimental to your whole team, it’s detrimental to our industry and the goals to improve software development.
In my opinion, it’s not just about experience that should give you the thumbs up to indulge in ScrumBut behavior. It’s the knowledge behind why the rules exist and determining whether or not your team is fulfilling the objectives behind the rule.
There’s an old anecdote about a woman who cuts a turkey in half before cooking. When asked why, she answers that it’s because it was what her mother and her grandmother always did. Upon further exploration, it’s determined that it originated because the oven was too small … something that was no longer true. We must question the rules and determine if they are right for the team. But don’t discount them too quickly. As Foy points out, experience also plays a part. If the rules work for most teams, figure out why they work. Unless there’s a big reason not to follow them, give them a try, even it’s not immediately apparent why they work. Then, reflect and adapt as necessary.
What do you think? Which rules of Scrum do you think are most important?
