What is Scrum?…really

My friend Johannes Brodwall recently pointed me to a short video by Alistair Cockburn called: Core scrum, barnacles, rumors and hearsay. Alistair uses the elegant analogy of barnacles to describe all the things that have latched on to Scrum over the years. In his view the essential parts of Scrum can be reduced to three things: release often, trust the team and continually adjust based on experience. I totally agree with all three of these propositions. In fact, you would be hard pressed to find an experienced agile practitioner that doesn´t. But is this the definition of Scrum? I would argue that this is a definition of the core values in agile. Alistairs three propositions easily translate to three of the four values in the agile manifesto. The only value that is not evident is the one about customer collaboration.

So what is the definition of Scrum? This is a surprisingly difficult question to answer. The harder you look the fuzzier it becomes. Different organizations have vied for the ownership of Scrum over the years. The definition of Scrum has also changed as people have gained more experience using it. Things have been added, changed and removed. What is common for all the definitions that I have seen is that they are a lot more detailed and prescriptive than what Alistair describes. So, maybe the definition of Scrum has been reduced to these three core principles? I hope not. As I said earlier, the definition Alistair describes is so broad that everyone agile fits in. Scrum would become synonymous with agile and all the alternatives to Scrum would suddenly be covered by it. Want to use a Kanban based approach without sprints? No problem, it would still be Scrum.

The reason Scrum became so popular is precisely it’s prescriptive nature. Companies that were looking for a “follow the dots” recipe for agile found it in Scrum. This worked in some cases but was a disaster in other ones. There are many really good Scrum gurus out there but also large numbers of dogmatic and quasi religious ones. If your context does not fit Scrum their answer is invariably: change your environment so that it works with Scrum. This can be great advice if the thing you are changing is something that is holding you down. It is terrible advice if the thing you are trying to change is part of what makes you competitive.

Instead of making Scrum so generic that anything agile can be called Scrum I would recommend that people explore the heuristics of when Scrum works and when you should use a different agile approach.

Niklas Björnerstedt

Posted on 2013.09.09 at 9:41

Comments are off for this post.