Can ‘Scrum everywhere’ be taken too far?

In the previous post Scrum everywhere with Joe Justice - Adopting Scrum outside of technology teams I facilitated a Blab discussion with Joe Justice of Scrum Inc. and Simon Bennett of LASTing Benefits on Scrum everywhere. Joe unfortunately had to leave the Blab part way through, and so in this post Simon and I continue the conversation, exploring the question 'Can Scrum everywhere be taken too far?'.

The recorded Blab is 7 minutes long and there is a transcript of the discussion below.

Blab presenters

Our presenters during the Blab presentation were:

• Left-hand side: Simon Bennett, Managing Principal at LASTing Benefits. Simon is a Certified Scrum Trainer and popular Agile speaker with a focus on the wider organisational issues in the areas of Agile contracting, employee motivation and systemic resistance to Agile & Scrum Adoption.
• Right-hand side: Ray Cooke, Lean and Agile business transformation coach, Equinox IT Wellington office. As a Software Development Manager Ray focuses on Agile software development approaches and the change required to successfully adopt Agile within teams and organisations.

Transcript of conversation

Ray: "Can Scrum Everywhere be taken too far?"

So I guess we've been talking about Scrum being used in organisations from top to button, and Joe's (Joe Justice from our previous Blab post in this series) example of Bosch, clearly they are using that all the way from the board down. But I guess are there situations, scenarios, in which actually Scrum is not the right thing to do? It's not appropriate. How might we define where those are?

Simon: I think there's actually a really simple example, which is, you shouldn't run a fire department from Scrum.

You shouldn't run an ambulance with Scrum.

Ray: Why is that?

Simon: Well, because it comes back to impediments. The whole idea of the sprints, the backlog, is there's a list of things we want to do, redefine anything that's not on that list is regarded as a threat to that list. And so Scrum actually has, as what Joe was talking about, multi tasking. All right? It's bad to multi task. We don't like to be interrupted in Scrum.

You don't want firemen working off a backlog. You can't give them...

Ray: I'd quite like them to be interrupted.

Simon: Yes. They need to be interrupted.

So, for a fireman, being interrupted is the job. It's not a dysfunction. It's not an impediment, and people that try to apply Scrum to things that are fundamentally unpredictable or interrupt driven just create suffering for themselves.

Ray: Absolutely.

So, in those scenario, there are processes that we can use. I mean, I guess from... There's a framework called Cynefin, which is a framework for assessing what type of complexity you're dealing with.

So I guess we're talking about the domain of the unknown unknowns, the unpredictable scenarios in which, actually, we're dealing with a complex environment, whereas Scrum does a good job of trying to turn complex environments into complicated environments. So I guess processes that live in the complex domain, like Cynefin, for example, might be a more appropriate thing to use in those scenarios.

Simon: Yeah. I mean, if you bring it back to Cynefin, fire, for example, is not a complete unknown unknown. You know that there are going to be fires. You know what to do, largely, when you get there. But you don't know when the fires are going arrive, or necessarily how many of them. So what you have to do is just have people with a tremendous amount of slack in the system.

If you go anywhere around Auckland or Wellington, we will find a lot of firemen doing push-ups, waiting for a fire to be there. They can't go, "We're at fire A and at fire B, and we've prioritised this in the fire Product Owner...". That's fundamentally ridiculous.

Ray: Absolutely.

Simon: But what I think Scrum does is say to a lot of organisations... We use this analogy in organisations. I have been spending all week fire-fighting, and we're not doing it in a heroic way. We're doing it in a way that we've created all of these organisational fires, basically, through our own confusion. We've actually taken something in Cynefin, which should be barely complex to complicated, and through being disorganised, we've made it, well, actually chaotic. So we are going through those act - sense - respond loops all the time, because we've let our service catch on fire.

We've let all these things get out of control.

Ray: On the flip side, though, there are organisations within which, actually, there are unpredictable events.

Simon: Yes.

Ray: I mean, support organisations, call desks, those sorts of things. Actually, you know they are going to come along, but you have no idea when they do.

As we've kind of said before, Scrum obviously doesn't quite fit. But for those, they are truly complex, and actually other processes like Kanban do deal with those well. I guess it's just identifying those that are intentionally unknown, as opposed to the ones, the problems, we've created ourselves. The fires we've created ourselves.

Simon: Yeah. I mean, if you go back to Scrum's real original... I'm talking about 1986 sort of Scrum, and it was designed as something to deal with what we call wicked problems in those days. A wicked problem was fundamentally something that didn't have a solution. So if you think about it, it's closely in line with what Cynefin would call complex. It's not like filling a glass you water. You can't go, "Right, once I have put 250 mls in a glass of water, then I have a glass of water."

All we can do is make things better or worse. As a result of there being no solution, there's no stopping rule. So it's not like, oh, I am now going drink the glass of water, and now that it's empty, it's empty. It's, there's no natural signal to stop, which is why they put in the time boxes. Which is, you've now done, in those days it was a month, because you were actually building hardware, not software. It was, like, right, now that you've spent a the time you want to invest another month. So the whole point of time was to put in an artificial stopping rule for something that had no end.

Ray: Is that true of all the problems that we're applying Scrum to, though?

Simon: No.

Ray: Actually, no. I mean, there's a lot of scenarios in which we've got a reasonable idea of what benefits and outcomes we're trying to achieve are, it's just the process of getting there is a bit misunderstood.

Simon: So, to be clear, I'm saying that this is where the time box and sum originated. If you read The New New Product Development Game, that's why time boxes were there. So that was Scrum's original context, was dealing with that, dealing with these fundamentally wicked problems, and I think this is what causes people to do what Martin Fowler calls a flaccid Scrum, where they start breaking all of the rules because they are not dealing with complex problems any more, they're dealing with complicated, and in a lot of cases, simple problems.

Ray: And, actually, they should just get on and analyse it.

Simon: Yes. They should just go ahead and do it.

It would be fundamentally ridiculous, like building a big map using a process respond loop, right? Big map is probably the most ontologically simple thing in the world.

Ray: Fair enough.

All right. So clearly there are scenarios in which taking Scrum in is not appropriate.