big

NOOP.NL | The Creative Networker

ScrumButs Are the Best Part of Scrum

03/09/2009

Scrumbut Many organizations in the world are adopting Scrum, and many of those are adapting Scrum. But the adaptation of Scrum is frowned upon by lots of practitioners, and Ken Schwaber even has a name for this "bad" practice: ScrumBut.

The pattern of a ScrumBut is like this:

<We use Scrum, but> <we have these unique circumstances> <so we have had to modify Scrum so it works here>

Here is a shorter description:

ScrumBut = (practice not being followed)(logical excuse)(workaround)

There's even a definition for it:

scrumbut [skruhmbut] noun.
1. A person engaged in only partial 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 tenants of the SCRUM methodology.
4. In general, one who uses the word "but" when answering the question "Do you do SCRUM?"

Well, I like ScrumButs. And here's what I want to say to all ScrumBut-bashing zealots:

The But of Scrum is the best part. If you can't swallow that, you shouldn't be teaching Agile!

I believe an explanation is in order, so here we go…

Scrum teams are self-organizing complex systems. The behavior of any complex system is a function of its structure and its environment. A process or method is a description of behavior. It describes how a system should behave to be successful in its environment. Scrum describes how a development team might be able to successfully deliver software to its environment. But… because optimal behavior is a function of internal structure and external environment, the real optimal method always depends on the team's structure and environment.

In short: the optimal method will always be an adaptation…

Here is a quote I used in my talk at Agile 2009:

A project cannot be viewed independent of its surrounding context [...]. An understanding of the context is in itself not sufficient to prescribe a method. Rather, the method to manage the project is embedded in the context and one must allow the emergence of such a method through interaction between the actors and the environment. [emphasis mine]

Pundir, A.K., Ganapathy, L. and Sambandam, N. (2007)
Towards a Complexity Framework for Managing Projects

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. It is impossible to design the process up-front. It must emerge, just like the design of the solution.

And that's what retrospectives are for!

It's OK to say "We do Scrum, but we don't do stand-ups because there are only two of us, and we already communicate all day."

It's OK to say "We do Scrum, but we don't have a ScrumMaster because we decided to share this responsibility with the whole team, just like in XP."

It's OK to say "We do Scrum, but we don't do fixed sprints, because just like in Kanban we have a continuous flow of releases, and in our environment iterations make no sense."

Of course, I understand that there are organizations that adapt Scrum for the wrong reasons, making it half-Agile, or even non-Agile (part 1 and 2 of the definition above). We might call these adaptations negative ScrumButs. They make a team's performance worse.

But if you do your retrospectives well, they should lead to positive ScrumButs, making the team's performance better, which is great! It is the best part of Scrum! Scrum is a great starting point for many teams, just like XP and Kanban. But unlike those others (and thanks to continuous improvement through retrospectives) Scrum is the only method that is able to morph itself into XP+retrospectives, or Kanban+retrospectives. And back again!

But only if you allow and cherish ScrumButs…

(picture adapted from Mountain Goat Software)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:

The Three Types of Change

Risk Management = Banana Peels AND Dollar Bills

Empowered, Whether You Like It or Not 

This article is written by on in Uncategorized. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://www.leadingagile.com Mike Cottmeyer

    Totally agree. The dogmatism of Many Scrum practitioners is counter productive. As long as you are not making changes to hide legitimate impediments, adaptation should be encouraged. Nice post!

  • http://refactor.co.za Rick Tonoli

    Nice article, as always, but I think something to remember is that “ScrumButs” sometimes become an excuse for not fixing a deeper problem.
    Like you say, the retrospective is of utmost importance but a keen eye has to be kept out of people adapting ANY agile process (not just scrum) because they’re afraid to confront an issue and would prefer to “work around it”.

  • http://mendeltsiebenga.com Mendelt Siebenga

    Scrumbuts are also the most agile part of scrum. Agile is about dealing with change. If parts of your process are off limits and can’t be adapted you’re less agile.

  • http://www.davenicolette.net/agile Dave Nicolette

    I agree with Rick. I call questionable adaptations “pain-killers”. See http://www.davenicolette.net/articles/pain_killers.html
    I also agree with Jurgen.
    IMHO all this fuss about Scrum and ScrumBut comes down to marketing. People who make their living by selling Scrum have an incentive to control the definition of Scrum.
    There’s also a question of goals. If your goal is to “do Scrum,” then of course you want to get a book about Scrum and follow it to the letter. Scrum is the definition of Good. IMHO this is pretty normal when people focus on the tool instead of on the job the tool is meant to perform.
    If your goal is to deliver software effectively to add value to the organization, then you probably see Scrum as a tool; one tool among many, to be applied when and as appropriate to help you achieve your goal. In that case, Scrum isn’t the definition of Good, and there’s no sin involved if you modify it.
    When you do modify Scrum, just be aware of the addictive nature of pain-killers, and stay alert to the true root causes of problems.

  • http://www.targetprocess.com Michael Dubakov

    That is what I am thinking about. Borders are blurring between agile processes and in the future I don’t think there will be separate processes. However I afraid that marketing trends in Scrum community will try to impedance this processes as much as possible. Will see what happen next 5 years :)

  • http://www.mountaingoatsoftware.com Mike Cohn

    To me a ScrumBut is a deviation from the minimal core set of Scrum practices that is obviously a bad deviation–e.g,. “We do Scrum but we run 8-year sprints.” There’s no chance that’s a possibly positive variation on Scrum.

  • http://www.dennisstevens.com Dennis Stevens

    Jurgen,
    Nice post. I agree with all of your points up to the last one. A Kanban team can absolutely adapt and morph to meet the needs of the business. At its simplest form, what Kanban does is make explicit to the team what Scrum leaves implicit. The visibility of work and the focus on continuous improvement makes it a very adaptable approach. In situations where it is easier to get the organization to start with a board, some wip limits, and a desire to continually improve software, Kanban may be a better starting point.
    I agree with Michael that borders are blurring. I talk about adapting the ScrumBut test to any agile team on Tuesday http://www.dennisstevens.com/2009/09/01/methods-practices-and-outcomes/.
    The goal is for the team to be able to identify the capabilities and outcomes that are most important to improving the teams delivery of quality code. Then building those capabilities and removing impediments. They should use whatever method of learning and adaptation works for them.

  • http://scrummaster.no Geir Amsjø

    Jurgen,
    I love the idea of making a clear distinction between “good ScrumBut” and “bad ScrumBut”.
    As I see it the good ones are a result of analysis of their particular context after having used Scrum “by the book” for a while.
    Sadly I see far too many bad ones. They just haven’t got it. Simple root-cause analysis almost always reveals a lack of understanding of the very concept of agile..

  • http://blog.xebia.com Serge Beaumont

    I would look at this from two levels: the “spirit” or “effects” of Agile, and the implementation. In my consultancy I do exactly what you describe: no two Scrum implementations are the same, reality in ALL cases makes a creative solution necessary. BUT… I ALWAYS make sure that what I implement achieves the spirit and effects you want out of Agile. Does the team swarm over and around its challenges? Is there a loop of feedback and learning? Is there focus on outcomes? And so on. If – in some context – that would need to be achieved by throwing, say, the Scrum Board out of the window, I wouldn’t think twice.
    It’s the mindset and effects you want, not the mechanisms.

  • http://www.cornetdesign.com Cory Foy

    Hi Jurgen,
    Normally I agree with you. But in this case I don’t. My replied ended up as a blog post:
    http://blog.cornetdesign.com/2009/09/scrumbuts-are-the-downfall-of-agile/

  • http://haxrchick.blogspot.com abby, the hacker chick blog

    I totally agree with you here, we should self-organize and adapt to what makes sense and works for US. And the way we work should be continuously improving – how can you continuously improve if you’re forced to stay the same?
    I think Ken’s point (or, at least the way I’ve chosen to interpret it) is not that we can’t change Scrum, but that when we change Scrum in a way that removes or severely lessens the whole Purpose of Scrum that it really isn’t fair to call it Scrum anymore. And I’m okay with that. I think where the argument comes in is at what point is it no longer Scrum.
    Scrum’s purpose, he says, is identifying problems with how we’re working (http://www.thehackerchickblog.com/2009/03/scrum-framework-for-finding-failure.html).

  • http://www.leanway.no Niklas Bjørnerstedt

    I agree with the basic premise that ScrumBut can be good in the right circumstances. What I don’t like is seeing so many projects that passively accept their environment and adopt a practice that in reality is not agile. I think this was the point with the original use of the term ScrumBut.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    I think I just have a problem with the word ScrumBut. It seems to include any deviation from Scrum, including the good ones.
    IMHO it is the perfect term for overzealous SM’s who focus on process instead of people and agile values.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Thanks for teaching me! :)

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    I would certainly believe it when 80% or 90% of the ScrumButs turn out to be negative ones. :)

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Couldn’t agree more :)

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    (In turns out Cory and I agree after all. It’s just a matter of wording and details. See our tweets and mutual replies.)

  • http://kallokain.blogspot.com Henrik Mårtensson

    I agree, BUT many business organizations are very poorly adapted to their environment.
    When an agile team adapts to their immediate environment instead of to the business organization’s environment, the team will find it easier to work within the business organization, but it does not help the business organization improve.
    Of course, if the organization as a whole does not improve, then there is no business reason for having agile in the first place. (It can still be a good thing for developers, though the advantages tend to evaporate when the organization returns to its original status quo.)
    I believe the agile movement would do well to link up with systems thinkers, TOC and Lean practitioners, SPC people, and others, who have tried to introduce sane management methods for more than fifty years.
    We can learn a lot from both successes and failures of others. We also have a good foundation for close collaboration because we have shared goals, and a great deal in common when it comes to basic principles and methods.
    Agile represents a much needed paradigm shift. Still, the best management methods today are one step ahead: They are paradigm transcendant.
    This means they allow managers to think and work not only using a good paradigm, but to work according to different paradigms depending on what they are doing. For example, one problem in a value stream might be best solved by Lean, another by TOC, a third by System Dynamics, a fourth by Queueing Theory, a fifth by statistical methods, and so on.
    Paradigm transcendence allows managers to pick the best approach for the job. A bit like a programmer choosing between Erlang, Ruby, and Java depending on what they want to do.
    The thing that makes implementing agile difficult, is that most business organizations use management methods that are analogous to machine code. High Level languages for managers have been available for several decades, but most managers do not know about them, or aren’t interested in using them.
    When most managers try to figure out what to do with an agile development team, they are in a position roughly equivalent to an assembler programmer who has never heard of high level languages trying to figure out what to do with a Ruby or Python library.

  • http://www.leanway.no Niklas Bjørnerstedt

    I’d like to introduce the term ScrumAnd. There are agile practices that expand Scrum without being in conflict with it. One example is working towards reduced release length. Se my post about this: http://www.leanway.no/?p=173

  • Cuan Mulligan

    good post, and I agree with you. My issue is when people are not doing scrum and say they are. In this case they are Scrumbut.
    I belive the original point of the term was to address the many companies and people who have jumped on the trend bandwagon and say they are doing scrum, but they are not.
    The refinement of the process to suit your specfic needs, is a worth while activity, but it is no longer scrum, it is your own custom method based on scrum.

  • Lowell Lindstrom

    In classic “blogger” form, you’ve taken a concept (“Scrum, but”), exaggerated a mis-conception (that it includes empirical adaptation), and then ragged on a community of people who use the term. You’ve even chosen to codify the misconception with you’re *new and improved* Scrumbut: positive and negative.
    Very lame. Rather than contributing by clarifying the intent of “Scrum, but” (what you call negative), you’re simply seeking attention with a provocative blog title. Disappointing!

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    If this is a case of “mis-conception” of the term then I’d suggest the community of people who use the term do a better job at defining it!
    I don’t see why _I_ should be made responsible for “clarifying” the term. I didn’t come up with it in the first place. Others did. Let them clear up the confusion then.
    I truly believe the term is badly chosen, badly defined, and gives process zealots a reason to rag on people who have good reasons for partial Scrum implementations.
    I suggest the supporters of this term redo their homework.

  • http://guilhermesilveira.wordpress.com guilherme silveira

    I couldnt agree more. Everything which is unflexible will break under some circunstance. If adaptation is the basement of any agile practice, not adapting it to fit your needs is a failure in itself.
    One should always be looking to improve its practices, no matter which name was given to it. I love adding the following question to those who think the set of rules should be followed as they are, no changes allowed: “this means that in 10 years from now, will scrum practices still be the best ones available?”… if scrum itself is unflexible, its time-unrelated, so 10 years later, it should be the same thing. now, believing that in 10 years, the same practices will solve new kind of problems seems…. like a set of fixed rules trying to say “i am the solution to everything… the silver bullet of management”. what have we learned about silver bullets?
    Again, not an excuse to do something crappy and think thats nice. But being “scrumbut” doesnt necessarily mean being worse or better than “scrum for this specific team and organization”.

  • http://www.clintonkeith.com Clinton Keith

    Good article. I also use “ScrumBut” to mean a negative deviation from the core practices. Often, instead of “positive Scrumbuts”, I’ve heard people say “ScrumAnd”. It’s not as catchy though.

  • http://borisgloger.com/en/ Boris Gloger

    Your post really cool, thanks for clarify that there is a positive ScrumBut. But I really believe this is the the wrong message politically.
    Why, because it will allow beginners not to force themselves to change. Change is not easy. A well educated and visionary ScrumMaster will use Retrospectives to change the teams work process to an adapted scrum work process.
    That was always the intention of Scrum. F.e. Alistair Cockburn starts with Chrystal on the more flexible more agile side than Scrum. And his version was not as successful as Scrum as it does not give people the frame they need to self-organize. It did not create strong enough boundaries. Scrum does create these boundaries.
    To change boundaries, will force the system to change also. So do not build the boundaries according to your actual needs but according to the desired output and success. So you might start with Scrum, if you do not get the desired outcome, change the boundaries till you get the desired outcome.

  • http://itknowledgeexchange.techtarget.com/software-quality Yvette Francino

    I blogged about ScrumButs the other day and referenced this post at: http://itknowledgeexchange.techtarget.com/software-quality/are-you-a-scrumbut-and-if-so-is-that-a-good-thing-or-a-bad-thing/
    Come join the discussion!

  • http://jchyip.blogspot.com Jason Yip

    I liked this up to the last part which implies that XP teams and Kanban teams typically don’t use retrospectives or some other improvement mechanism.

  • http://scrumcrazy.wordpress.com/ Charles Bradley

    A ScrumBut is a ScrumBut. They’re not all negative, but in my experience, the vast majority of them are.
    For instance, the overhead required for Scrum is only really valuable, according to Ken anyway, for teams of 5-9 developers. You’d be hard pressed to convince me that truly doing Scrum works for 2 person teams.
    Why is it that people who do ScrumBut can’t just admit that what they do is ScrumBut?
    I think it would be ok to say, “We do Scrum, but we do x and y differently from Scrum, so technically we don’t do Scrum ‘by the book, but we find our adaptation to work better for us.”
    Why can’t one just be honest about it? It it is totally up to the receiver of that message to determine whether or not the ScrumBut is negative or not.

  • Brian Marick

    One small beating of a hobbyhorse of mine re: “the method to manage the project is embedded in the context”. I was heavily involved in context-driven-testing http://context-driven-testing.com/ before Agile. A striking difference of emphasis between the two is that Agile is much less accepting of the context and the need to adapt to it (to find a solution “embedded within it”). I have at times referred to Agile as context-driving rather than context-driven, including I think in this lightning talk: http://www.youtube.com/watch?v=iRoH_zKu5mQ
    To me, the most likely distinction between positive and negative scrumbuts is that the former are active and constraint/environment/context-challenging, whereas the former are passive and accepting of constraints.