When Scrum Doesn’t Work
Scrum is not designed to solve all problems in all business domains. There are times when Scrum used properly is a great fit for complex problem solving. But when and where does Scrum not work? When should we not be using Scrum? When would it be too much overhead for the value derived?
Professional Scrum Trainers Greg Crown, Jason Malmstadt, and Robert Pieper will explain more on the subject in this video blog.
Greg: Sometimes Scrum doesn’t work. I know it’s true, but it might help for some of our viewers to know when Scrum does not work. When is it a bad idea? That’s the topic that keeps coming up in our classes, even our Scrum classes. People are buying Scrum, but they shouldn’t use it sometimes. What do you guys think about this?
Robb: Yes, absolutely. Scrum is not for everything. Let me pick on one set of problems. Simple and complicated problems have recipes. For example, making chocolate chip cookies over and over and over again. I love using that example. When you’re making the same thing over and over, why do you need a Sprint Review? It’s the same thing over and over. Your stakeholders are like, “This is the exact same thing I saw last week.”
Another example: manufacturing automobiles. If it’s the same car over and over and over again, there’s nothing interesting about that. There’s no uncertainty in the output. You know what you’re building, and you know how to build it. Scrum doesn’t offer any benefits here.
That’s my thought. I mean, What about a help desk? Jason, you were mentioning a help desk at one point, what are your thoughts there?
Jason: Just like you don’t need a Scrum Team to change a tire or something that’s very formulaic. If you’re on the opposite end of that spectrum and you have no idea what’s coming up ahead or you don’t even know where you’re going, you’d be in that chaotic space where Scrum isn’t going to help you. If you can’t define a goal, if you can’t define a backlog of work to do, it’s just sort of triage.
Like in an emergency room situation where it’s just new things coming in the door and, or an IT help desk. I had someone in a Scrum class say to me, “Hey, this all sounds great to me, but I don’t know what I’m doing Thursday until Wednesday, at best. I don’t have a backlog that I can work off of, I don’t have a Product Goal, I’m just sort of putting out fires as they come.” This is when I say to them, “Scrum may not be a good fit for you in that situation.”
Greg: I’ve got something that’s kind of a derivative of your help desk model. I think what we find in some companies is that there’s more of a mandate model, or more of a requirement based building. They think: “cool, we’re gonna use agility in our company”, but there’s still the mentality of “these 20 requirements must be completed by…” and then there’s a date out there in the future, November 13. Everyone’s locked into scope, time and budget, and there’s absolutely zero flexibility. Scrum doesn’t really work in those environments. I really think of those as kind of a push system, there is not an opt in for the type of work that’s driven with problem solving. It’s more of a mandate with requirements. Somebody from above, typically within the hierarchy, has said, “make it so” and teams are there to hit a deadline, no matter what. I find that to be kind of a similar situation, a bit more of a mandate system, usually due to leadership styles and techniques.
Those are three very different perspectives, and I liked them. I think it’s kind of blended, maybe that’ll help some of our viewers and readers know when “not” to use Scrum. It’s not for everything. There’s a time and a place, and there might be an evolution in your work cycle in which Scrum might be available, but hopefully this might help kind of be that litmus test for you.
