News Stay informed about the latest enterprise technology news and product updates.

Are you a ScrumBut? And if so, is that a good thing or a bad thing?

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?

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Guess I'm a Scrum But.....and damn proud of it! Once again we go back to my complete dislike of the current state of A... (I still refuse to utter the "A" word) Rules! If you're truly A.., if you are truly flexible, there are no rules....just guidelines. If you begin enforcing "rules" like iteration lengths, stand-up or no stand-up, etc., then A... just becomes another rigid - my way or the highway - process. Rules? We don't need no stinkin' rules!
Cap'n'Dave! Great to see you out here! I still want to nail you down for an interview! Love to hear from someone who doesn't mind speaking up for his beliefs!
I have to say I agree wtih capndave. I like agile with a small a. We follow the daily scrum but really its not a stand up, sometimes it lasts longer than we want it to. We also tried to follow the rules but then started modifying it to fit what our team needs to do.
I am a proud Scrumbut also. So what's your objective? Pray at the altar of Agile and get a Certificate that you followed every rule there is to follow or Develop Software in a better way? I propose the term "ScrumFiend" for those zealots who adopt the rituals of Scrum without understanding the Lean Principles behind it. If you understand why Agile works, you would not be so anal about the rituals!
I see this quite a bit and often team fail to realize that many of the Scrum practices are risk mitigation strategies. "Cherry Picking" exposes projects to additional risks. So, if you choose not to apply a certain Scrum practice, then you simply need to understand the risk you introduce to your project and determine some way to mitigate the new risk. Short iteration lengths, daily meetings, co-location, and so forth are there for a reason -- ignore them at your own peril.
I love to see the comments and debate here! Which rules (if any) do you think are the most important in Scrum?
Mschedlb - I agree with [I]'Short iteration lengths, daily meetings, co-location, and so forth are there for a reason — ignore them at your own peril." [/I] The struggle we are having in our team is that we are moving from extreme waterfall to agile and the transition has not been easy for everyone in the team. We have to give in (or give up some rules) to get the best we can from the team.
Yvette, and others, I think you're mistaking Cohn's (and [A href=""]others'[/A]) warnings about ScrumBut for over-rigidity of the Scrum process. The expectation is that Scrum/Agile will be tailored. Eventually. What's problematic is when people tailor Scrum before they've mastered the underlying principles. The "rules" are actually designed to cause some pain and thereby surface organizational issues and impediments that need addressing. Many companies will simply predict that XYZ rule will cause some pain and promptly remove it from the process without realizing that they've done themselves a disservice. I've seen plenty of organizations take early shortcuts that lead to trouble down the line. Some of which include: - Ignoring the call for collocated cross-functional teams because "QA is all located in India" - No single person named to "Product Owner" role since no one wants to sit in the hot seat (or because people are too busy) - No ScrumMaster because the role is not well understood and management considers it wasteful - No timeboxing b/c we have "complex" problems to solve here - No clear "done" criteria on Stories/Backlog Items since that "takes too long" - this list goes on and on There is a difference between doing these things from a place of understanding their full consequences and doing these things on day one because you can't think of a convenient way to do it. I think that's general warning call against doing "ScrumBut". Good luck to all of you embarking on Scrum.
Our "ScrumButs" that seem to work: (1) We have short discussions during the stand up. The whole team has been good about self-regulating these into meetings when needed, and 1 minute of discussion with the whole team often saves hours of work without the overhead of a separate meeting. (2) We report how we spend our time in our daily scrum meeting as part of "what did you do" - just how many hours spent on each Scrum task. It's greatly helped with identifying weak spots in estimation. (3) Our iterations are only 3 weeks. I'm not sure why, since that policy was started before I joined the team, but it works fine. (4) We have one remote team member who never attends anything in person, as he is a couple time-zones away. He attends every scrum meeting by phone, and is good at maintaining open lines of communication with the team. He also used to be co-located, which does seem to help, since most of the team once worked with him in person. The one "ScrumBut" that I think has bitten us is accepting unclear "done" criteria for a Sprint. No one likes making specs, so often we end up working out specs with the chickens as we go . . . which often hurts QA velocity, since any tests written early on have to be checked over and often rewritten as the spec changes. Our team has started being pretty insistent on reviewing the spec before accepting a feature for a sprint, and that has helped tremendously. Avoiding "verbal specs" in favor of a wiki page with a Q&A section for every sprint story has also helped deal with small details that weren't foreseen when the specs were written I think there's a point where teams realize that Scrum is helping them a lot, but they still need to tweak processes to fit their people. Scrum seems to naturally encourage this, even, through the "retrospective" meeting.
Insightful comments! Keep 'em coming!