Why “Scrumbut” Shouldn’t Be a Bad Word

There’s a term that gets floated around the Agile world by what I like to call the “textbook Scrummers” that really bugs the crap out of me, so much that I decided to write an article about the concept, and why I think it’s a wrong-headed, anti-agile concept.  The concept is known as “ScrumBut” (a shortened form of “We do Scrum, but…”) and as the folks at Scrum.org describe it:

ScrumButs are reasons why teams can’t take full advantage of Scrum to solve their problems and realize the full benefits of product development using Scrum.

In theory, this concept sounds harmless — after all, Scrum is a very specific methodology, with specific ceremonies and deliverables that are designed to achieve specific goals and specific benefits. The problem lies in the fact that these methods are not the only way to achieve those goals, though the companies who provide Scrum training would be loathe to admit it.  Here are a few reasons why “ScrumBut” really isn’t as bad as those “textbook Scrummers” might have you believe…

“ScrumBut” is Inherently Anti-Agile

The first and most important reason that “ScrumBut” simply can’t be as bad as the Scrum folk want us to believe is that it flies in the face of one of the fundamental principles of Agile outlined in the Agile Manifesto:

Through this work we have come to value…individuals and interactions over processes and tools.

And Scrum is just that — a process.  If we are truly to be Agile, then we should always value individuals and interactions over processes and tools — and this includes the processes outlined by the Scrum methodology.  If we feel or discover that the specific ceremonies, practices, or deliverables of Scrum are getting in the way of our interactions as individuals, then it’s our duty as Agile practitioners to modify those elements so that they work with our organization.  Sure, there’s a good reason to have stand-up meetings on a daily basis, in a physical room, with a tracking board — but these things are not the reason why we do them; they are means to an end.  If your team is highly collaborative, then forcing them into a daily stand-up might be counter-productive, and simply raise their ire and cause more frustration than it solves.  If having a standup on M/W/F or on T/Th, or having a virtual stand-up via email or slack works better for your team, then who is some outside consultant to judge you because you’ve made a choice that values those individuals and interactions over processes and tools?

“ScrumBut” Implies Perfection at the Start

The idea that you are only “doing” Scrum if you’re doing everything that Scrum tells you seems rather counter-intuitive  — effecting any change in an organization isn’t something that happens overnight, it’s a process, and expecting perfection at the outset of the implementation of that process is basically setting the team up for failure.  Yes, I know — “ScrumBut” doesn’t come into play until your team is “fully engaged” in Scrum, and has already implemented all of the ceremonies and processes.  In theory, all of that sounds very noble and good.  But the reality is that it can take years for an organization to be fully engaged across the company.  If the direction that these people are getting is that Scrum is an all-or-nothing proposition (which is precisely what “ScrumBut” does), then the change agents who are trying to make incremental changes have yet another hurdle to overcome, one tossed into the fray by the very people whom we want to provide support to our efforts.

“ScrumBut” Stifles Innovation

Scrum comes from a revolution in the software development world — the establishment of a new and different way of doing things that became known as Agile Software Development.  But somewhere along the way, dollars took over for principles, and the “better” way to do things somehow became the “right” way to do things.  There’s a common belief in the software business that if you’re not doing Scrum, then you’re not Agile (or even “agile”).  To that, I say this: bullshit.  Scrum was the product of revolution, and like any group of revolutionaries who suddenly find themselves in a position of authority, the “powers that be” in the Scrum world don’t want to lose ground, or power…or dollars.  How much does each of the Scrum certifications cost — in time and money?  How much money is passed between companies and consultants, trainers, and “coaches” who simply deliver the Gospel Truth of Scrum, and then want to come back again and again in the name of fighting against that dreaded villain, “ScrumBut”?  This is not agility — this is a specific, defined, structured framework that tells you what to do, when to do it, how to do it, and who should be involved. By virtue of its stricture, Scrum stifles any attempt to innovate, to improve, and to adapt Scrum into something new, different, and (dare I say it?) better.  Because if you’re not strictly doing Scrum by-the-book, then it’s “ScrumBut” and you’re doing it wrong.

“ScrumBut” Means Well…

Look, I get what the Scrum organizations are trying to get at — they’re trying to avoid both “cargo cult” mentalities where the ceremonies are technically followed but nobody knows why, and at the same time trying to ensure that people follow a framework that has been proven to be successful for decades.  It’s not an ignoble goal, and organizations who practice “ScrumBut” because they really don’t want to follow Scrum, or they’re giving up too easily, or they don’t really buy into the concepts underlying it really aren’t getting the value from the practices that they should be.  But the concept that “ScrumBut” is inherently evil, or to be avoided at all costs, or is an entirely unacceptable way to proceed, is entirely false and needs to be called out.  Rather, when we hear “ScrumBut” we should question whether it’s really intended to limit our options or challenge the value we’re getting from our chosen methodology.