Project Management: How to Know When Scrum is Appropriate

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

When development organizations first consider adopting Scrum, an agile project management approach with clearly-defined roles and processes, there is often confusion about where the use of Scrum is appropriate and where it's not. Here, Knowledge Center contributor Jimi Fosdick dispels two pervasive myths regarding where Scrum cannot be used, considers what kind of work is appropriate for Scrum, and describes the keys to Scrum success.

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.

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 He can also be reached at

Submit a Comment

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

Rocket Fuel