eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Scrum is an agile project management approach with clearly-defined roles and processes. Before we discuss when an organization can adopt Scrum, it is necessary to first dispel two pervasive myths about where the use of Scrum is not appropriate.
These myths, often based on incorrect assumptions about what Scrum is and what it requires, are often the first and biggest obstacles organizations face when deciding to adopt Scrum.
Myth No. 1: Scrum only works with small teams and doesn’t scale to the enterprise
This is an extremely common and understandable myth. It derives from Scrum’s requirement to use small, cross-functional teams. A Scrum development team is supposed to include five to nine people comprising all of the skills required to do all of the work required. This is so they can successfully develop a fully-functional, fully-tested increment of the product under development each sprint.
However, it’s worthy to note that although Scrum requires small development teams, it places no restrictions on the number of cross-functional teams that may work on a single product. Obviously, any sufficiently complex product will probably require more than five to nine people doing the work if they want to finish in a reasonable amount of time.
The answer to this problem is to use multiple teams of five to nine people, all working from a common Product Backlog (the primary release planning artifact in Scrum), and adopting one or more patterns for communicating across teams from iteration to iteration.
Thus, scaling Scrum to the enterprise is certainly challenging, but a large organization is not an insurmountable obstacle to adopting Scrum. The issue has more to do with organizational culture than with the requirement of using small teams. Enterprise software development is complicated and difficult. While this is no less true when using Scrum, neither is it more true.
Myth No. 2: Scrum Wont Work on a Fixed Schedule and Budget
Myth No. 2: Scrum won’t work on a fixed schedule and budget
This may be the most common myth one hears when first introducing Scrum concepts. This myth, too, is understandable given the dramatic differences between a Scrum approach to planning and execution and a more traditional approach such as “waterfall.” Scrum uses a planning approach called “progressive elaboration” or “rolling wave.”
Rolling Wave Planning is “a form of progressive elaboration planning where the work to be accomplished in the near term is planned in detail, while the work far in the future is planned at a relatively high level, but the detailed planning of the work to be performed within another one or two periods in the near future is done as work is being completed during the current period,” according to the Project Management Body of Knowledge (PMBOK) Guide, Fourth Edition.
Such an approach is in stark contrast to a traditional approach where we construct an elaborate, up-front plan that contains the details of all the work to be done (we think), and project health and progress is measured by deviation from this baseline plan. This is referred to as a “plan-driven approach.”
Scrum is based on a completely different set of assumptions. Scrum assumes, in the words of quality management guru Philip Crosby, “if anything is certain, it is that change is certain. The world we are planning for today will not exist…tomorrow.” For the kinds of work where we would consider the Scrum approach (typically, complex creative development work), Scrum recognizes that we cannot reasonably determine all the details of the work up-front and won’t have a fuller understanding-no matter how long we think and talk about it-until we start building something. Scrum then replaces a defined process, the plan-driven approach, with an adaptive and evolutionary process that’s referred to as a “value-driven approach.”
Scrum: A Value-Driven Approach
Scrum: a value-driven approach
The belief is, that a value-driven approach like Scrum, which dispenses with a “complete plan” up-front, sacrifices the predictability of a plan-driven approach. This belief would have merit if there were any evidence that software and other complex creative development projects were predictable even in principle. The history of software development suggests strongly that they are not. The work of software guru Steve McConnell (building on the work of Barry Boehm) suggests that project estimates at the beginning are wildly speculative (wrong by a factor of four).
Based on Barry Boehm’s well-known Cone of Uncertainty, which is predicated on a single-pass, phased development model (aka “the waterfall” approach), we can see that we don’t have anything like predictability until perhaps halfway through the project timeline. Not only that, but the observed rate of project failure in the software industry (according to recent reports) tells us that only 32 percent of software projects are successful. This implies that achieving predictability and control using a plan-driven approach is the real myth.
In addition, Scrum provides its own set of metrics (based on empirical observation of sprint results) that absolutely allow strategic planners to monitor project health and progress as well as, or better than, traditional methods. So, then, it’s clear that the bar is pretty low for increasing project performance. The truth of the matter is that Scrum will not greatly improve the initial predictability of our projects but it certainly can’t do worse.
That said, with Scrum’s emphasis on delivering the highest value features first, eliminating features that contribute negligibly to ROI and continually evaluating what’s most important, Scrum will deliver the best product we possibly can-with the time, money and people we have. In addition, Scrum doesn’t make us wait until halfway into a project to tell us if we’re in hot water or not.
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.
Keys to Scrum Success
Keys to Scrum success
With all that said, what are the keys to an organization’s successful adoption of the Scrum approach? While there’s no magic formula, there are a few rules of thumb we can use as guidelines for whether or not our organization is ready for Scrum.
First and foremost, we must have a problem to solve. In other words, if what we are doing presently is working, there isn’t much reason to take on the risk of adopting the Scrum approach. Scrum is hard and disruptive. Adopting a Scrum approach will immediately surface all the dysfunction in our organization and in our teams. There’s little reason to confront that dysfunction if our current approach is working to our satisfaction or if we’re lucky enough to be free from such dysfunction.
Assuming what we’re doing presently isn’t working to our satisfaction, the next key to achieving success with Scrum is the willingness of our people and our organization to make a change. Scrum requires a radical shift in how we think about what we’re doing and our willingness to change. This is the most difficult part of adopting Scrum as our development approach.
Generally, we need support at all levels of the organization. We need people who recognize the need for change and a willingness to take a chance on a new way of doing things. A lone change agent is going to face an uphill battle when trying to change an entire organization and its people. It’s not impossible but it is decidedly more difficult.
Finally, our best chance for success is a willingness to change and a diligent effort from both the “bottom up” and from the “top down.” That said, even a handful of people at various levels of our organizational hierarchy can be enough to make the changes required.
What’s really needed is for the people doing the work to be willing to take personal responsibility for what they’re doing, and for managers to trust and empower their people to do just that. Given the right attitude and a passion for what we’re doing, adopting Scrum can result in a dramatic change in our organization. This not only improves the lives of the people involved, transforming the world of work, but also makes a profound impact on our bottom line. Given the right circumstances, everybody wins.
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.