When Scrum fails

David Andersen used his Meetup talk i Oslo last week to describe a start-up’s journey from Scrum to a more Kanban based way of doing things. I seldom work with start-ups, but David’s talk resonated with my experiences in contexts that have little do do with start-ups. I summarized the insight in a tweet:
“The Meetup with @agilemanager yesterday reinforced my belief that Scrum works best when you are in a state that you should avoid being in”

I freely admit that as tweets go, this one is pretty cryptic. A lot of people did not understand what I meant. Others stumbled into false logic and thought I was implying that Scrum does not work in most contexts/states. No! That is not the point. Scrum works for a lot of people and in a lot of different contexts.

The point I was making is this: One of the core ideas with lean start-ups is that you have to get your product “out there” as soon as possible. The real feedback you get when you have real customers is invaluable. At the the other extreme, my experiences with large corporate replacement projects has taught me the same lesson. Get the new system in parallel production as soon as possible. A few years ago this led me to create a wiki that collected patterns and insights for how to do this. But once you have succeeded in getting real users for your product, things tend to get complicated. These users will demand that you fix problems quickly and address missing features as soon as possible. All of this can be handled in Scrum, but it gets progressively harder the bigger this pressure is. It is also easy to fall into one of the traps that can ensnare a well meaning scrum master:

The valiant gate keeper

A couple of years ago, I talked with an experienced Scrum master in a large project. He was very satisfied with the Scrum had helped him shield the team so that they were able to complete their sprints. The team was very satisfied with his work and they managed to deliver lots of features at the end of each sprint.

I recently met a woman that had been on the business side of the same project. She told me that this same team had not worked very well in terms of the project as a whole. The Scrum master’s insistence on shielding the team had lead to considerable problems elsewhere in the project.

I honestly believe that both the Scrum master and the businesswoman were truthful in their descriptions. The Scrum master had succeeded in helping his team deliver value but at the same time this had come at the cost of being too inflexible when unforeseen problems occurred.

Sprint fiction

Would things have been better if the Scrum master had been more flexible? I’m not sure. I recently coached a team that was having trouble adopting Scrum. After observing them for a while I realized that up to 50% of the work they were doing in a sprint was not foreseeable at the start of the sprint. When you also take into account that they worked in a highly specialized environment where tasks could not freely be reallocated to other team members you get a situation where sprints are bound to fail. So in this context, flexibility was helping the business as a whole, but it was making a mockery of the whole idea with sprints.

Now, a lot of people will read these descriptions and their heads will be bursting with ideas for how to have done things better. That is not the point! Of course you can do better! The fact that you can do better does not invalidate the observation that Scrum gets harder to implement the more chaotic and interdependent your environment is. I think Scrum can be great in some contexts and that you can handle these types of problems… up to a point. But once you pass that point you should seriously consider looking at a more Kanban based approach. (I am not going to tell you where that point is. That you must find out for yourself.)

Niklas Björnerstedt

Posted on 2012.02.06 at 20:48

Comments are off for this post.