When Scrum Is Appropriate
When Scrum is appropriate
So, then, if Scrum isn't proscribed because of team size or constrained schedules and budgets, how can we tell if Scrum is appropriate for a given project? It really comes down to two factors: requirements agreement and technology certainty.
Business professor and organizational dynamics theorist Ralph Stacey illustrates this with the Stacey Complexity Matrix, which divides problem spaces into different categories based on how close we are to agreement about the issue and how certain we are. When considering software development problems, the variables are how close we are to agreement on requirements and how certain the technology we plan to use is.
The Stacey Complexity Matrix
In the lower left of the Stacey Complexity Matrix, we're in a position where requirements are close to agreement and the technology we plan to use is certain (that is, stable, mature and we have lots of experience using it). This corresponds to simple problems. According to Stacey, simple problems are amenable to "technically rational decision-making and monitoring form of control." In other words, a defined process and plan-driven approach will work well for these kinds of problems.
At the other end of the spectrum, when we have little or no agreement about requirements and the technology is mostly or completely uncertain, we have "anarchy." In that category, there is no process or policy we can take that will avoid "disintegration and chaos" and we should basically avoid that situation entirely.
Scrum, then, is appropriate for problems living between simplicity and anarchy. That is, when our agreement about requirements is variable but not unknown, and the technology is somewhat but not entirely certain, we should consider Scrum as a useful approach. It turns out that this is where most software and product development problems live. Thus, Scrum is appropriate for a wide variety of applications and situations typically found in software and product development. It doesn't have much, if anything, to do with how big our organization or project is or the constraints on our time and budget.