Is Scrum the Best Choice for Any Kind of Work?

A frequently asked question in Scrum classes is this: ”Is Scrum best for every type of project?” My answer is “No”. I will explain this answer in three different ways in my next 3 posts. In this one, I will present  a mashup four-quadrant model derived from two prior sources that gives us an easy way to compare two fairly obvious work characteristics to known process frameworks.

Four Quadrant Models

I have a personal theory that anything in the universe can be described with a four quadrant model. Someday I may create a four quandrant model to make my case. I want to share one here that is a mashup of other diagrams I have encountered in the past. The main inspirations are

• The “Stacey Chart” used in the past by many Scrum experts to show the choice of process model (defined vs. empirical) given the level of uncertainty in ways or means. Here is an example: http://www.agileconnection.com/article/managing-value-agile-software-development.
•  A diagram I saw drawn by Jez Humble at Agile2011.  http://www.infoq.com/interviews/jez-humble-agile2011

When to Use What

The axes are similar to the Stacey chart mentioned above. The horizontal axis represents the level of knowledge about the problem to be solved. The vertical axis represents the level of knowledge about the solution to the problem. Each quadrant in my model has a “best” fit for framework. Let’s walk through them to see how if you agree with me.

In the lower left quadrant, the problem to be solved is well known and solutions to it are also well know. An example might be building a dog house. You can get plans with a materials list and build one on the weekend. Been there, done that. What about a real house? Sure, if it is just like a house that has been built before? A bridge, skyscraper? Maybe. This is where the traditional Waterfall model works just fine. You can create a plan and then execute the plan. This has been the default for software development since the 1970’s. Sometimes it works just fine. Sometimes it does not. If you are going to create a software product that you have created before, it might work fine. But who does that?

The upper left quadrant represents a known problem but an unknown solution. Remember that there are gradations in these quadrants, so we might not totally know the problem. And we may know some possible solutions to try out. But, in general, this quadrant represents experimentation in the solution space. This is the sweet spot for Scrum. We work iteratively, testing our solution with the customer in small steps and correcting course as we learn more about the problem (or perhaps the real problem that was not fully understood by the customer) and hone in on workable solutions.

The upper right quadrant is where we don’t know for sure what the problem is and therefore can’t reasonably know a good solution. OK, some people think they have a solution for anything but we are interested in efficient solutions here, not so much one-size-fits-all stuff. In this quadrant we see the Lean Startup framework. Lean Startup is essentially experimentation in the problem space. It starts with an idea for something new or with a hypothetical opportunity to test. Then, using short iterations of lightweight experiments, we hunt for a viable business case. Each iteration leads us to stay the course, pivot to a different course or bail out before we waste too much investment money. Once the “problem” or opportunity is defined, the modes shifts left and experimentation on the solution takes over. Lean Startup can precede Scrum implementation.

The bottom right quadrant puzzled me for a little while. We don’t know the problem but we do know the solution. What does that mean? Having recently worked with some Operations people at one client, the answer came to me before too long. Kanban is the framework of choice here. In essence, we do not know what problems are going to show up but we are ready for them by having the right people with the right skills and tools. This quadrant represents a service situation. I have seen Kanban used effectively in departments that have an ongoing input stream of unplanned work to react to. These include customer support, software maintenance, procurement, facilities and even recruiting.

There are a couple of other points to be made while we have this chart in front of us.

1. Some teams do both product development and maintenance. A combined framework has evolved called ScrumBan that allows the team to use Scrum for the planned work and Kanban for the reactive work. At first glance this seemed like an overcomplication made by combining two simple frameworks. But I have seen it work pretty well.
2. I described the lower left quadrant as being the place for Waterfall, but Scrum works just fine there, too. Data show that shorter waterfall projects tend to be more successful than long ones. Scrum has shortness built in via short sprints. So I would predict that a lower-left quadrant work effort would probably turn out just as good with Scrum or even better because you never know when another dog might show up to share that doghouse.
3. We described this chart as if the work is software-related. It does not have to be so restrictive. Scrum is used for a lot of different kinds of work: software development, infrastructure buildouts, fund raisers, hardware design, any collaborative endeavors.

In the next post, we will look at the title question in another way using a Value Stream Map.