Ken Schwaber, a co-creator of scrum, says that roughly 25% of teams trying the method realize the gains they had hope. More teams call themselves “Scrumbut”, “Scrumerfall”, or “Scrumish” than claim to be doing it right.
It is as if something conspires to make Scrum ineffective.
Let me be frank.
Scrum is designed to expose problems. It does not, by itself, solve the problems. In theory, Scrum provides a framework for the team to work through the solution themselves. In practice, politics, rhetoric, and lack of training often get in the way.
But that’s if you have the framework in practice, if you are actually doing it.
There is another challenge in tailoring the work – in getting to there from here, wherever here is.
I teach a class called Lean Software Delivery. In one of the exercises we inject waste, forcing the team to do things a specific way. Then we talk about the exercise and talk about waste and flow; it is common for people to recognize the wastes in the exercise they just did. Then slowly, over a couple of more exercises, we take the constraints away, asking the teams to do the same thing any way they would like.
After doing this with a few hundred people, I’ve see that something like 60% of the teams continue the work incrementally. They may remove a constraint or two, but they make small improvements, continuing along the same line of thinking that we started with. A smaller percent, perhaps 20%, make no attempt to change the system at all — they inject cool new technology, but the work remains the same.
Here’s the thing: When people try to adopt a new thing, any new thing, they tend to be “primed” with however they did work before. “We’ve always done it this way” is powerful.
So when teams are told to ditch waterfall and go to two-week sprints, we see a two-week requirement sprint followed by a two-week architecture sprint, a design sprint, some coding sprints, and some “hardening sprints.”
It’s usually not quite that bad or obvious, but it is a common pattern with the teams I have been working with the past few years, overlaying whatever the team did before with a little bit of Scrum on top. I call this “ScrumJemima”, and, sort of like taking a burnt pancake and adding syrup, it doesn’t work very well.
We have to change the way we make the pancake.
Rising to the challenge of tailoring is something I’ve been talking about for a year or so, and thinking about for a lot longer than that. It is a theme in my CAST2014 talk last summer, and something that Markus and I talked about into the wee hours of the night at Agile2014.
In 2015, I’d like to talk about it more, starting with a talk called “Save Our Scrum”, some writing, and a possible tutorial.
Scrum can be a powerful framework; let’s make it work for us.
You know where to find me.