Scrum – When to Use It, When to Avoid It

By Joshua Render on February 4, 2019 • ( 1 Comment )

Scrum has been too often shoved into situations where it has no business being. I know Scrum proponents will often tell you Scrum is versatile and it can go anywhere – it can’t. There are jobs that are too big for Scrum.

Scrum is a lightweight approach. It is great in some situations, such as the ongoing and long-term development of a product with a small team, or long-term projects with structured support that already exists and doesn’t need to radically change.

Things then go bad when Scrum is forced to fit.

Scrum works in situations where you have a small team of developers constantly evolving a product.
Scrum works in situations where the product can be handed off to someone else after every release.
Scrum works when you don’t need extensive support for your development team

Using Scrum outside of the bounds of what it does best, will either cause you to have to build support for things Scrum doesn’t handle; or it will cause you to hate Scrum and believe it doesn’t work. To a person uneducated in Agile, it will cause you to hate Agile. Agile isn’t the problem, the choice of approaches is.

Where won’t Scrum work:

When projects or products need built-in support that Scrum doesn’t provide
In larger teams with more than 9 people
Organizational level Agile adoption – When your whole organization adopts Agile
When your product needs more than a reliance on “fit for purpose” or minimum viable product to be sustainable
You need more control over the product backlog
When you cannot or do not know how to handle code development over the long haul (creating a condition known as flaccid Scrum)

Alternatives to Scrum with a Fuller Lifecycle Approach:

Dynamic Systems Development Methodology (DSDM)
Scaled Agile Framework (SAFe)
Disciplined Agile Delivery (DAD)

Alternatives to Scrum with More Development Support:

Extreme Programming (XP)
Test-Driven Development (TDD)
Feature-Driven Development (FDD)

The below video is about 45 minutes long, but if you have the time, check it out. It enlightening to learn how a Scrum Master role evolved (around half-way through) and rotting code created by a Scrum team: