When Scrum Is Appropriate

 
 
By Jimi Fosdick  |  Posted 2010-10-29 Email Print this article Print
 
 
 
 
 
 
 


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.




 
 
 
 
Jimi Fosdick is a Certified Scrum Trainer at CollabNet. With more than 14 years of experience in product development, Jimi has worked in a wide range of industries, including publishing, software, advertising, and the public sector. As one of the Certified Scrum Trainers on CollabNet's ScrumCORE team, Jimi conducts dozens of public courses around the world each year, helping organizations to surface dysfunction and improve processes through Scrum. Before joining CollabNet predecessor Danube in November 2008, Jimi spent four years advocating agile approaches to project managementÔÇöfirst as a program and project manager, and later as an independent agile and Scrum consultant. During this time, Jimi worked with companies such as CIBER, Avenue A | Razorfish, MTV Networks, and Microsoft, helping them transform to more agile ways of working using Scrum. Prior to these consulting engagements, Jimi spent a decade working in various capacities in software, including as a program manager of software product development and solutions architecture at the Riverside Publishing Company, and as a senior staff developer at Polycom, Inc. Jimi is a PMI-certified PMP, and received his MBA in Project Management from Keller Graduate School of Management in Chicago. As an undergraduate, Jimi studied mathematics and computer science at Loyola University in Chicago. For more of Jimi's thoughts on Scrum, visit his blog at http://blogs.danube.com/author/jimi-fosdick. He can also be reached at jfosdick@collab.net.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel