I am asked this question a lot: Should we use Scrum on our “DevOps team”?

Of course the answer is nuänced. So let’s jump right in.

First off, I’m never one to say you should use Scrum (or any other specific process). So I’m not actually going to answer that particular question. Instead I’ll ask a related question: “Can Scrum make sense on a DevOps team?”

And that leads us to a question that my long-time readers will immediately predict: What do you mean by “DevOps team”?

I believe that “DevOps team” is an oxymoron. It’s more accurate to say that DevOps is a culture of cooperation. Nobody would ever consider having a “Cooperation team”.

But of course this doesn’t really help us know whether Scrum makese sense. So let’s try to address the question that someone probably meant to ask.

In my experience, “DevOps team” usually means one of two things:

1. A single, cross-functional team that handles development tasks, and operations tasks.
2. A team that handles operational concerns, which other development teams use as a platform.

If you’re asking about #1, Scrum should work as well as it would on any other cross-functional team.

However, if you’re asking about a platform team, the answer is much more nuanced.

Unlike a feature team, platform teams usually have two types of tasks:

• Improvement tasks (such as “Install a new instance of MySQL” or “speed up the CI pipeline”)
• Ad-hoc requests (such as “Why is my CI pipeline failing” or “One of our nodes is in a crash loop”)

Improvement tasks can work well within the Scrum framework. But support requests and incident response does not, for the simple reason that it cannot be planned.

A core concept of Scrum is the Sprint Goal. A sprint succeeds when the goal is achieved. It fails when it doesn’t.

Short of using platitudinal goals such as “Respond to all support requests”, there’s no way to include unpredictable, ad-hoc requests in a Sprint goal. I see this as a strong indication that Scrum is a bad fit for interrupt-driven teams.

Of course many teams do a mixture of both types of work. Can you use Scrum for half of your backlog, and something else, for the the interrupt-driven work? Probably.

Is it worth the extra overhead? I leave that up to you to discuss with your team and decide.

But my personal preference is to leave Scrum to the feature teams, and use something lighter weight and reactive for teams that handle more than a minimum of interrupt-driven tasks.