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