≡ Menu

ScrumButs are the downfall of agile

I normally am in good agreement with Jurgen, but not in with his new article. The ScrumBut Ken argues against aren’t targeted towards mature agile teams.

The fundamental problem we have – in Scrum, in XP, in Crystal – is that teams don’t want to even *try* the practices.

  • “There’s no way I can sit next to someone all day”
  • “Our code is too complex to write tests first”
  • “We don’t need stand-ups because we’re already communicating well enough”

It’s about context. If you’ve tried the practices, and have valid reasons why it doesn’t work for your team, and how you overcome that, then you are likely at an organizational maturity level past that which is the target of ScrumBut.

Further, there is nothing wrong with dogmatism when it is for the sake of learning and gaining context. Saying to a team, “I realize that we do X, but why don’t we go all out and try Y, since the XP book says that it is a good practice” – is that really a problem? It is being dogmatic, and then you use inspect and adapt against it.

My recent post about the CSM being the VB of Agile applies here. What gives the software development industry a bad name? It’s not the time to solve a problem. It’s that we don’t pick the right problems to solve, and when we do solve them, we can’t maintain or tweak them. That comes solely out of people not taking the time to actually adopt clean code practices.

Such is the case with the agile software world. What gives the CSM a bad name? The people who take a two day course, go back and cargo cult adopt Scrum in their organizations, don’t follow the practices (especially the one that says “Inspect and Adapt”) and then – and here’s the kicker – go to their conferences and say, “We do Agile!”

This is utter crap. 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.

So yes, the “But” is a vital part of maturing as an organization. But (pun fully intended) saying, “If you aren’t tweaking Scrum then you aren’t doing it right” is, in my opinion, actually a harmful statement without the context of “once you’ve tried the practices for several iterations, and reflected as a team about what is working and what isn’t”

Now, does that mean a team shouldn’t start with a Kanban board? No. Not at all. If your team can level stories properly, can discuss flow states and is willing to give it a try, you are already past the maturity levels of a large majority of teams. I still think you should try both to be able to compare and contrast, but hey, if you don’t, I’m not going to fault you.

I’ll close this out with this. As a former Firefighter/EMT, there were plenty of times when we or our Paramedics had to stray from the norm to solve out-of-the ordinary solutions. But you only strayed once you had the experience and ability to understand the consequences of your decision. And until you had that, you trained and experimented and trained and reflected and discussed and trained until you did.

So I find nothing wrong with the default and general advice to be not to tweak until you have the context necessary to be able to tweak. And for mature teams, that may be early in. But you don’t know until you try, and saying you should tweak without trying I think has led us to the exact situation we’re in – an industry of unmaintainable, untestable, low quality, low value crap.

Comments on this entry are closed.

  • Jurgen Appelo September 3, 2009, 9:49 am


    Actually, I think we’re in agreement, and we’re just nitpicking on the finer details. :)

    Like I said in my post, Scum-by-the-book is great as a starting point. I simply believe that the need for (some) adaptation starts with the very first retrospective.

    Though I agree that practices shouldn’t be ditched unless you know what you’re doing, I also think it is vital to know what you’re doing as soon as possible!

  • Ari Tanninen September 3, 2009, 10:01 am

    Powerful tools can be dangerous in the hands of inexperienced users, and Scrum is a pretty powerful tool.

    You and Jurgen are talking about the different sides of the same coin. Like you wrote, it’s a matter of experience.

    ScrumButs are dangerous to beginners who don’t understand what they are doing nor what the consequences will be. They should stick with dogma and avoid ScrumButs. But for practitioners who know what they are doing ScrumButs are vital.

    What a shame that so many beginners aren’t aware of their own level of understanding.


  • Mike Cottmeyer September 3, 2009, 11:19 am

    Is Scrum the best starting place for every team? If you can do EVERYTHING in Scrum… I’d agree.

    Way too many teams are working in matrixed organizations, not on dedicated teams, not co-located, don’t have dedicated product owners… etc. etc.

    These teams try to do the three roles, the three rituals, and the three artifacts and call it Scrum when their very structure is not supportive of what they are trying to accomplish.

    There is so much grey here… but we need to start educating large organizations what it takes to even BEGIN to try Scrum. Laying Scrum on top of disfunctional organization sure does expose the dysfunction… but you’ve got to be ready to fix it.

    Many aren’t.

  • Tim Ottinger September 3, 2009, 12:54 pm

    This is “Shuhari” all over, no? What is appropriate for the master is not appropriate for the novice. http://agileinaflash.blogspot.com/2009/04/shu-ha-ri.html

    The problem with “scrumbut” is that it is either a reasonable position for someone who is at “Ri” or a completely unreasonable position for someone at “Shu”. The problem is that a lot of people want to be masters without first becoming masters.

    When Kent Beck says *but*, I listen. When some guy who was living the waterfall dream says *but*, I have a different reaction. When the “but” comes out before the “shu” then the bozo bit is flipped.

    So I guess I’m saying the value of the scrumbut has less to do with the “scrum, but” and more to do with the quality of agile experience of the one saying it.

    In other words, some people are experts and some are hacks… just like in coding.

  • Yvette Francino October 11, 2010, 11:26 am

    Hi Cory,
    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!