I’m a Scrumbut and I’m proud of it.
What is a Scrumbut?
Ken Schwaber, one of the creators of Scrum, defined Scrumbut like this:
ScrumButs are reasons why teams can’t take full advantage of Scrum to solve the problems and realize the benefits. Every Scrum role, rule, and timebox is designed to provide the desired benefits and address the problems. ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.
That might be the official line but I believe the definition given on Fragile: In Defence of Scrum but reflects common usage:
scrumbut [skruhmbut] noun.
1. A person engaged in only partially Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenents of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”
The third bullet point is really the essence of the definition: “One who adopts only SOME tenents of the SCRUM methodology” although the fourth bullet point provides the measuring stick ‘one who uses the word “but” when answering the question “Do you do SCRUM?”’.
The definition also captures the derogatory aspect of the phrase that some Scrum purists apply, e.g. "You are a Scrumbut" rather than the less personal "Your process is Scrumbut".
I guess the Scrumbut tag is meant to apply to adaptations that will break Scrum. For example:
- We do Scrum but we don’t have a Product Owner
- We do Scrum but we kept our Technical Lead
Both of these examples would attract the label "Scrumbut" from the Scrum folk. (Personally I’d be worried about the lack of a product owner but I’m okay with having a Tech Lead.)
The big irony for me is that the Scrum authorities encourage XP practices to fill in gaps within the Scrum framework. You’d think a person that did that would be a Scrumbut however that is, apparently, not the case.
I do Scrum but I also do XP technical practices as Scrum encourages a technical mess
It seems using XP technical practices doesn’t make me a Scrumbut. Here’s an excerpt from a recent official Scrum Alliance email:
If you’re looking for ideas on ways to help your team improve, be sure to have a look at the technical practices of eXtreme Programming (XP). In particular, you’ll want to read “The Land that Scrum Forgot” (http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot), an excellent article by Scrum community member Bob Martin. It examines the “mess” that a Scrum team can sometimes create and how eXtreme Programming can solve this kind of issue when it arises. XP often proves very effective at instilling discipline into the highly productive framework of Scrum.
If you read the Bob Martin post you see the Scrum Alliance quote is a bit mis-leading. They claim something that Martin doesn’t actually say. It wouldn’t make sense to use both XP and Scrum and Martin doesn’t suggest this. Martin does think that Scrum teams can rapidly make a mess and that adopting the technical practics of XP can help prevent that.
I do Scrum but I also do XP Release Plans because Scrum can’t help me forecast when I’ll be done
It seems that XP style Release Planning is also exempt from the Scrumbut tag. Mike Cohn, one of the big Scrum names, recommends Release Planning in conjunction with Scrum (at least he did on the courses I’ve been to).
Despite Mike’s backing Release Plans are still not official Scrum. The 2011 Scrum Update 2011 says “Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself”. (Personally I favour a release plan over the Scrum product backlog because Scrum has nothing built in that enables a team to predict how much they’ll be able to build by when. This is important to me because I usually work in the context of a fixed price/budget.)
Why I care
I find use of the term Scrumbut rather arrogant and contradictory. On the one hand the Scrum authorities are saying the only good Scrum is the the Official Scrum. And deviating is not allowed and attracts a derogatory label. Admittedly for new comers this rather draconian attitude might be beneficial; at least they know what is officially endorsed and hence have a chance of knowing what can work out of the box.
On the down side this attitude encourages followers of Scrum to turn off their brains and leave the thinking to the Scrum authorities. Authorities who make a living from selling Scrum training and certification. And that is where Scrum starts looking like a cult.
The irony is that those same authorities acknowledge that there are some perfectly good practices outside Scrum, like the XP technical practices and Release Planning, that can be used in conjunction with Scrum. But, for example, replacing the Scrum product backlog with an XP style Release Plan risks attracting condemnation in the form of “Scrumbut” accusations.
Personally I’m interested in delivering software and doing that the best way possible. If I thought Scrum would give me that I’d do Scrum. If XP gives me that I’ll do XP. If Kanban offers something I need then I’ll get all lean. If an eclectic mix is best then I’ll get eclectic. I think about what I do rather than accept what gurus and such like say. I encourage everybody to do the same.
This is why I advocate people Go Deep on Agile Practices: Who, What, When, Where, Why and How. It is also why I’m proud to be “Scrumbut”.
Steve,
this is an excellent post and nicely puts what many of us in the Agile community feel. I personally think the people who use the term Scrumbut without any thought are the people who get excited by the words governance and PMO or have little real Scrum experience. Thinking back to the Agile manifesto “responding to change” over “following a plan”. Having a ScrumbutWhy attitude is much more helpful, “so you don’t have a backlog” – why?. Knowing the answer, what you lost and what you gained is surely far more important that just following a set of rules.
My experience of who uses “Scrumbut” is slightly different. Yes, recent Scrum converts have a tendency to use the term but also those at the centre of Scrum. Ken S. has written about it and used the term in a conference presentation I attended. More interestingly Mike C. covers the term in his CSM training. Indications are that other CSM trainers cover it as well. The term seems to be part of the fabric of Scrum. All that aside I agree that knowing why you’re doing, or not doing, a practice is the most important thing.
I think Scrum became like the Bible. Way too many rules and recommendations. And if you are “not that performant” someone can find a “sin” against Scrum and say “That’s why you are not performing well!”. Since no one can adhere to all rules an overpayed Agile coach/consultant can always deflect responsibility by pointing out a miniscule trespass against the book.
For me nothing beats sitting down and analyzing the process that created the problem. It could mean that we may change Official Scrum sometimes, because our Specific Needs should overwrite General Recommendations. Also processes need to be adapted to the specific field of the software as requirements on testing, planning can really-really differ, i.e. a medical software needs more testing than your smiley-handling logic in your chat program for teens.