How to Know when Scrum is Appropriate

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.

- See more at:

Jimi Fosdick


The Scrum Jump

When making the jump from project manager to ScrumMaster, behaviors and techniques that worked well before may work against you in the new paradigm. Here, two experienced project managers and Scrum trainers share their experiences and insights on navigating this challenging transition.

When transitioning from a traditional project management approach to an agile project management method such as Scrum, every part of the organization is affected, from each team member to upper management and everyone in between. Scrum is a radical departure from traditional management strategies, and this change is often perceived as uncertain or perilous for project managers.

Jimi Fosdick and Tamara Sulaiman Runyon are experienced project managers who both made the transition to ScrumMaster — they refer to the process as “jumping the shark.”

Jimi Fosdick