Agile Does Not Equal Scrum: Know the Difference

I have a problem with the way many people talk about Scrum. They say “agile/Scrum,” as though they’re the same thing.

No, no, no. Scrum is just one way to approach agile. It’s a terrific project management framework, especially for cross-functional teams that work on one project at a time.

Scrum does not say anything about the technical practices. The team is supposed to retrospect to determine which practices they need to add, subtract, or change. The team is also supposed to remove its impediments as it proceeds.

Agile works because it manages the work in progress and focuses on delivering finished value. Scrum manages the work in progress with iterations. Kanban manages the work in progress with an explicit board. Extreme Programming manages the work in progress by focusing on technical excellence.

I have seen teams do what they call Scrum. They don’t finish features in an iteration, and they don’t use the technical practices. Then they say, “Agile/Scrum doesn’t work for us.” Well, it can’t work if you don’t use it right.

I happen to be a fan of all three approaches for a collocated cross-functional team. I like one- or two-week iterations using Extreme Programming technical practices so we deliver finished products incrementally each week or two. I like using kanban boards to see where the work is and to limit the team’s work in progress.

If you look at the way I like to work, it could fit into Scrum. It could fit into kanban. It could be XP. And that’s just for collocated teams.

I happen to like more project management to deal with impediments for a distributed team. Teams that started as distributed or dispersed agile teams might not need the help of a project manager-type person to remove impediments. They might need servant-leader managers to build and maintain the agile environment for the team.

In my experience, teams who started as distributed or dispersed waterfall teams have trouble using agile, especially Scrum. Scrum has several real-time rituals: iteration planning, the daily standup, the demo, and the retrospective. Many teams accustomed to working out of sync find these practices difficult to manage.

In that case, I like using timeboxes for focus, but maybe not one- or two-week timeboxes. (I like four- to six-hour timeboxes for stories.) Kanban is good for helping you keep track of the work and limit the work in progress. When the team can make smaller stories, it has options for how to deliver value often.

Agile is broader than just Scrum. Scrum, for some teams, is a straightjacket that doesn’t fit. Agile, assuming you can see past the Scrum rituals, might fit quite well.

Let’s choose our words carefully. If you only know about Scrum, consider learning about kanban and Extreme Programming too. You might discover there is a wealth of possibility for improving your team’s process.

2 thoughts on “Agile Does Not Equal Scrum: Know the Difference”

  1. Dr. Charles (Chuck) Suscheck

    Great blog. As a trainer I’ve been saying the same thing.
    You can be agile and not use scrum – lots of people do and are successful.

    You can use scrum and not be agile. Companies do this and then wonder why scrum isn’t producing results. The mechanics of scrum support agile but by themselves don’t automatically lead to agile (flexible, empirical, shared risk) behavior.

    1. Chuck, thanks. So many people try Scrum, and they don’t use all of it. They think they’re doing Scrum, but they’re not. They don’t realize they can do iteration-based agile and not use Scrum. As you said, Scrum supports agile, but does not automatically lead to agile behavior.

Leave a Comment

Your email address will not be published.

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

%d bloggers like this: