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.
The Clever PM
The Clever PM has been a B2B product manager for over 10 years in a variety of industries, and is a passionate advocate for agile, effective Product Management. This blog is devoted to providing tips, tricks, and hacks to make people better, more clever Product Managers.
Follow Me:
What is ScrumBut?
It’s explained in the first paragraph, basically it’s a combination of “Scrum, but” where people don’t quite do Scrum, which is deemed by the powers that be in the Scrum world as an inherently bad thing.
I like the sentiment behind this post, but I don’t like people or organizations who describe their process as “ScrumBut” or say something like “we do Scrum, but…”. It’s so poor for communication, which is hard enough in software engineering. We already have enough ambiguous terms or words that we don’t agree on the meaning of across teams, organizations, or individuals.
Scrum is a very specific process that (according to its creators) implements the Manifesto for Agile Software Development and the 12 principles behind it. There aren’t a whole lot of rules behind Scrum. The whole process is described in 17 pages of English text (including a title page, a table of contents, and some end notes – closer to 15 pages of actual content, and there’s still generous white space). If you aren’t doing what is described in those 17 pages of text, don’t say that you do Scrum or imply that you are doing Scrum. That doesn’t mean that you aren’t embracing agility in your software development process. It definitely doesn’t mean that you are doing anything wrong. Scrum is not the be-all-end-all of agile software development.
But communication is hard. If you say “I do Scrum…”, that right there implies certain things about your process. These things are defined in the The Definitive Guide to Scrum: The Rules of the Game (The Scrum Guide). It’s a handful of specific roles, events, and terminology.
We have enough ambiguity in communication. We don’t need to add more.
A specific example.
My company is in a regulated industry. One of our requirements is that we have an independent software quality assurance. That is, the people who perform verification of the software need to be independent and separated from the people who write the production code. This is a hard requirement. The software engineers do test (writing unit tests and integration tests, primarily), but there are separate manual and automated testers who work at a system level of acceptance testing.
Scrum, when defining the Development Team, says that there are no titles or no sub-teams. We have a separate software quality assurance role that is part of evey development team. This person does not write any production code, but coordinates activities with the team. We don’t strictly adhere to what is described in The Scrum Guide.
I would never describe this process as “We do Scrum, but…”. It’s too confusing. We draw heavily upon Scrum for our process, but we break key rules that make Scrum, well, Scrum. Are we agile? Absolutely. But saying “we do Scrum, but…” doesn’t help in explaining our process or our rationale to people.
I totally get what you’re saying, and it’s a tangential issue to the focus of my post. That said, though — if you’re doing standups and retrospectives and planning and almost everything that Scrum says, but not *quite* in the way it says, then it’s helpful shorthand to say, “We use a process like Scrum, but tailored to our specific needs as a company.” Then you can describe the variations in your process and the reasons for them — without having to explain the 20 features of Scrum that you have adapted to your needs. As for the Scrum Guide being the “rules of the game” — that’s just marketing, positioning, and messaging to keep the consultants, trainers, and other members of the Scrum organization paid. Scrum started as an experiment, and it should continue to be experimental and flexible — otherwise it’s no longer an agile process in any meaningful way.
This is a growing sentiment about those of us who really what to help people work better together by engaging people. Well Said!
Thanks, Tammy — too many people have bought into the “this is the way” directives about Scrum and forgotten that the entire point of Scrum was to be an agile process that requires adjustment and adaptation. The goal is to deliver working software that solves valuable customer problems, not to follow some externally-prescribed methodology.