Scrum – When to Use It, When to Avoid It

rugby-3697512_1920Scrum 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:

For some additional resources:



Images from

1 reply »

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.