Scrum is an agile approach for developing innovative products and services. This chapter provide an overview of Scrum and where it can be applied.
What Is Scrum?
This section provides a brief overview of the Scrum framework as an approach for developing innovative products and services.
Here you are provided with a brief summary of the history of Scrum dating back to th 1986 Harvard Business Review paper that started it all, entitled The New New Product Development Game (by Takeuchi and Nonaka). It continues on with a mention of the first Scrum software project in 1993, with a reference to some notable publications since then.
This section provides a description of my experiences at Genomica Corporation (a bioinformatics company in Boulder, Colorado) in 2000. I walk through the problems we had pre-Scrum that motivated us to use Scrum.
Since I walked you through the Genomica story, I thought you would be interested in seeing what results we achieved after we adopted Scrum. Spolier alert! We kicked butt in comparison to our pre-Scrum days, requiring 1/10th the effort with a 7x improvement in velocity and delighted customers!
Can Scrum Help You?
Here I challenge you to ask questions like: "Are you happy with your development results?", "Do you delivery good value in a timely manner", etc. I then go on to speak to the benefits I see many companies realizing by adopting Scrum:
- Delighted customers
- Improved return on investment
- Reduced costs
- Fast results
- Confidence to succeed in a complex world
- More joy (who wouldn't want that!)
Next I describe when is it appropriate to use Scrum. Or as some prefer to think of it, "When not to use Scrum?" Meaning, is Scrum always the proper tool to take out of the toolbox? Of course not. To describe when Scrum is a good fit I introduce the sense-making Cynefin Framework (from David Snowden), which defines the following domains:
- Complex Domain -- where things are more unpredictable than they are predictable. Scrum is particularly well-suited for this domain.
- Complicated Domain -- where there might be multiple correct answers, and expert diagnosis can figure it out. Scrum can certainly work in these environments, but there might be expert-level approaches that are better tuned to the needs.
- Simple Domain -- where cause and effect is obvious to everyone. Although Scrum could be used here, this is really a domain better suited to a well-defined process (perhaps something like waterfall).
- Chaotic Domain -- where we are in a crisis and need an immediate rapid response to re-establish some order. Scrum is not the best solution here.
- Disorder -- where we don't know which of the other domains we are in. We don't try to apply Scrum in this domain, we are trying to get out of this domain as fast as we can.
Although not really a separate section in this book, this part discuss how Scrum may not be the best fit for interrupt-driven work. Instead a process like Kanban might be a better fit. I give a very brief overview of Kanban at this point.