There’s not much wrong with Scrum. Or is there?
It depends what the meaning of ‘wrong’ is.

In an earlier article, I explored Giles Bowkett’s call for Scrum to “die in a fire”. I pointed out that even Giles himself knew Scrum wasn’t supposed to be the way he experienced it, and I pointed to the aspects of Scrum that allow a team to — no, demand that they — improve their situation.

Scrum doesn’t say to tolerate negative behavior from managers. It doesn’t say to spend a hour in a fifteen minute meeting. It doesn’t say to take other people’s estimates. It doesn’t say to take on more work than you can do. As far as I can see, Scrum doesn’t advise any really bad ideas, although there are a couple of cases where a team might find an equally good idea, or even a better one.

Nonetheless, teams like Giles’s somehow wind up hurting so badly that they wish Scrum would die in a fire.

Scrum != Scrum

At the base of Giles’s concern is that Scrum does not equal Scrum. The thing he calls Scrum — that his company calls Scrum — is not the thing that Jeff Sutherland, nor Ken Schwaber, nor Giles’s Scrum teacher, nor I, call Scrum.

Now, this always happens. Whatever good idea we have will be misinterpreted by everyone who hears it. That’s due to the fact that our idea isn’t perfect, we ourselves probably don’t understand it perfectly, and we cannot perfectly express even the parts we do understand, while our listener doesn’t hear everything we say, doesn’t completely understand what they do hear, modifies what they understand before they even do it, and can’t do it perfectly anyway.

Man, that’s depressing!

No wonder the world is so screwed up. It’s a wonder we get anything done. But let’s explore what we might do about the situation.

Framework, not Method

Scrum is a lens. Work is done under the lens, not by the lens.

Scrum is a framework, not a method or process. It is designed to be as incomplete as possible. It nails down just three roles, five activities, and one key artifact: the current version of the product. It has one simple command: Inspect and Adapt. That’s the fundamental notion: do this stuff, observe what happens, improve it.

Giles’s team, with the best of will, were unable to improve things. We don’t know why: we weren’t there. We may have some suspicions. We know one thing for sure, Inspect and Adapt wasn’t working. Another thing we know for nearly sure: if you aren’t working to improve, you’re very unlikely to improve by accident. Gile’s team sure didn’t. They devolved to the point where they were in pain. Giles wisely left. Quite likely others did as well. Sometimes that’s all you can do.

Let me emphasize that. It’s easy to say to Giles, or to anyone, “You should have worked to improve things”. Yeah, well, don’t should on people. Some of us stick our necks out, offer ideas, try to gain influence or control, try to improve things. That’s often a Career Limiting Move. You don’t see me working for anyone, do you? There’s a reason for that.

Most of us didn’t get into computing so that we could work with people. If someone doesn’t want to work the people problems, or gets tired working the people problems, that’s OK. I hope they improve their situation some other way, such as by finding a new job. But whatever they do, they get to choose as best they can. For them, the choice to fight City Hall may not be the best.

Nonetheless, Scrum “on the ground” is often very different from “Scrum as it was intended”.

I started to say “as the experts intended”. Naturally, I had in mind experts like me. And since I got to go to the Agile Manifesto meeting, and I got to be on the first Extreme Programming project, and have thus far written three books relating to Agile software development, I was thinking I get to think I’m an expert.

But presumably the Certified Scrum Trainer who taught Giles’s course was an expert, too. And, I suppose, the people at Giles’s company thought that the people who went through that two day course were also experts. And that the people who had heard about it were experts. And so on.

Who’s an expert? Darned if I know. There’s sure a whole bunch of stuff that I don’t know, so probably I’m not an expert. I’m pretty good, though. Trust me. Really.

See what I mean? How do you know if someone’s an expert, giving you the straight stuff, or just some blowhard with a web site?

Judgment

It takes judgment, brains and maturity …
– Prof Harold Hill
(private communication)

Here’s that old Inspect and Adapt thing again. The team has to look at their situation and decide what to do. They need to look beyond Scrum: Scrum has no answers. Three roles, five activities, a couple of lists, and “done software”, remember? All the good ideas are outside Scrum.

So you look at what hurts, you use your judgment, brains and maturity to select something to try. If it works you might try more of it. If it doesn’t, try something else. Inspect and Adapt.

What about that fire?

Bad Scrum should die in a fire.

Today, the bulk of Scrum training is the two-day ScrumMaster class, or the equivalent from other organizations. In two days, a good instructor can get across the rudiments of Scrum, give the participants some experiences that may inspire them to dig into Scrum, and maybe get across to them that these are the first two days of a life-long journey.

In their enthusiasm, I suspect the participants forget that last bit before they’re out the door, and certainly before the next Monday at the office is over. Life-long journey, ha! I’ve got an hour and a half of Fifteen Minute Daily Scrum to attend. No time for life-long journey here. Get outta my way, Certified ScrumMaster comin’ through.

There is more material out there. There’s Certified Scrum Developer and Certified Scrum Professional. There are approximately 1,000 CSMs per CSP, which gives you a sense of how many people recognize the value of the higher rating and push forward to get it. So far, not many.

Nonetheless, from the data we have in the surveys, and from the continuing demand for CSMs and PSMs, people think they’re getting value from Scrum and Agile.

Should Scrum die in a fire? I sometimes think so. But mostly I think Bad Scrum should die in a fire.