Both basic Scrum and 2nd generation approaches like SAFe and Smith/Sidky[1] make a number of assumptions about the type of work, team composition, location and stability, project governance and other factors. Examples include the expectation of a stable, experienced, co-located team of about 7 members, daily availability of a single product owner, etc. The expectation is that you should conform your environment to these ideal conditions to assure Scrum success. However, in making those assumptions, they are essentially saying that projects that can’t or don’t meet those assumptions are less likely to be as successful using Scrum-based approaches.
Although not explicitly stated as assumptions, typical projects in the literature describing successful use of Scrum are also:
- Consumer facing
- Treat all users equally (i.e., few or no special cases)
- New features or processes or small feature sets that can be built on an existing platform or solution
- Low-to-moderate complexity
- Repeated development of similar products as is done by specialist consulting companies
Projects described in the literature as successfully using Scrum are typically not:
- Infrastructure projects
- Products where cost of failure and/or rework is expensive
- Products in domains where substantial regulation applies (e.g., transportation, healthcare)
- Creating replacements for legacy systems and processes where original constraints (or requirements or user expectations) remain in effect.
- Unique implementations for the team where they lack prior experience in the product area, as would be typical of business IT units.
There are significant elements of software project management that neither Agile nor Scrum address. Elements like the initiation phase, architecture, and environment building, and change management are critical activities in managing software projects that are not incorporated into the Scrum method.
So, following from the expectations of pragmatic project management, PMs should evaluate the use of Scrum per project, leveraging those elements that best fit the needs, omitting those that do not, and using included elements during the phases in the project lifecycle where they provide the most effectiveness and value.
[1] Becoming Agile, Greg Smith & Ahmed Sidkey, section 3.3.2 “Characteristics that make agile easier to adopt” and section 3.3.3 “Roadblocks that others have overcome”
