Kanban vs Scrum: 6 Golden Rules to Help You Pick the Right One

Let’s settle the Kanban vs Scrum debate for good.

There are tons of other project management methodologies out there, by the way. Have you wondered why these are the two so often confused with each other?

Well, though the frameworks differ, the principles behind them are largely the same.

Both are iterative work systems with roots in agile. Both focus on delivering early and often with continuous process improvement. Both break projects into smaller, more manageable chunks. Which has blurred the lines between them and created some confusion over which to choose.

Truth is, you don’t really have to—both can also be used at the same time. But when? And why might it make more sense to choose one over the other?

To decide, you’ll need to understand a few key differences. Then I’ll guide you through your options.

Kanban vs Scrum: what’s the difference?

Before I get into how they differ… a quick history lesson on where they originated.

Scrum was first introduced in Japan by two college professors who argued the old, sequential approach to developing products would no longer get the job done. Hirotaka Takeuchi and Ikujiro Nonaka recorded these early ideas in a now-famous (at least within the agile community) 1986 HBR article titled The New New Product Development Game.

Having observed the inner workings of companies like Honda, Epson, and Canon, Takeuchi and Nonaka noticed a few common attributes of the teams that managed new product development successfully. The six characteristics they came up with are still very much valid today:

1. Built-in instability: The team has the flexibility to figure out for themselves how to achieve the sprint’s goals, kept purposely broad to encourage trial and error.
2. Self-organizing project teams: Per the ‘86 article, you know your team possesses self-organizing capabilities when folks are autonomous (able to make their own decisions), self-transcendent (introspective while keeping an eye on the bigger picture), and cross-fertilized (essentially, cross-functional).
3. Overlapping development phases: Rather than the traditional “relay-race” approach to product development, where progress isn’t made until one group passes the baton to the next, Scrum teams favor the “rugby” approach, where “the ball gets passed within the team as it moves as a unit up the field.” That’s where the term Scrum comes from.
4. Multilearning: That is, team members are able to learn (a) three-dimensionally as individuals, as teams, and as an organization and (b) across multiple functions.
5. Subtle control: The team is autonomous but not completely un-controlled. Scrum aims to maintain a balance between chaos and creativity by, for example, mapping the right people to the right tasks, creating learning loops, and integrating customer feedback.
6. Organizational transfer of learning: The team actively shares wisdom across levels and functions, as well as with stakeholders outside of the group.

These foundation blocks come together to drive that “new” rugby approach. The point of the overlap is for team members to be able to absorb each other’s bottlenecks rather than let bottlenecks grind the entire process to a halt.

And here’s where Kanban comes in. As part of their explanation of the differences between the relay-race and rugby approaches, Takeuchi and Nonaka described three different levels of overlap—of which Kanban comprises the most:

• Type 1 = No Overlap
• Type 2 = Minimal Overlap
• Type 3 = Lots of Overlap (Kanban)

In fact, Kanban dates back even further. Toyota first started toying with the idea in the 1940s to improve the efficiency of vehicle production.

So how exactly does Kanban distinguish itself? Without further ado, let’s break down the distinctions.

What is Kanban?

Kanban, which literally means billboard in Japanese, is a visual approach to project management. As the name suggests, Kanban workflows are arranged on a Kanban board, where the team can visualize them as a group. This visual planning helps teams collectively prioritize tasks, minimize cycle time, and ship work earlier and more often.

And it’s easy to use. Kanban is known for its simplicity and works best when the board isn’t overly complex. You simply move tasks in an order that makes sense along some variation of the standard to do → doing → done format. Trello is a good modern-day example.

Get this Kanban workflow template here.

Though Kanban boards were originally used by agile teams for things like user storyboarding and backlog planning, these days there’s little any knowledge worker can’t do with them.

What is Scrum?

Scrum is an incremental approach to project management. It’s a standardized process that structures work into sprints: cycles of a set intervals (commonly two weeks or 30 days), punctuated by daily Scrum and retrospective meetings to keep things in motion. Each sprint is broken into predefined tasks that must be completed before the next sprint can begin.

Unlike Kanban, Scrum is a highly prescriptive way to get things done. And while Kanban doesn’t have to be, Scrum is strictly iterative in nature. But that doesn’t make it any less agile. The fast sprints are designed to allow for—nay, encourage—flexibility and adaptability to change. Although changes are made more holistically, they’re still made often.

Get this Scrum agile template here.

As I said, you don’t have to pick one method over the other. But each has its pros and cons to consider.

Kanban vs Scrum: which method is best?

It’s a common question. But disappointingly difficult to answer. It depends! On your project, your goals, the ways your team works best.

But when you understand which method works best under what types of circumstances, your answer should reveal itself. Use the following rules of thumb as a guide.

If you’re in a rush to get started or want to see immediate results, start with Kanban.

(You can always pivot later.)

Because Scrum teams are self-organizing, they work best when led (not managed) by a Scrum master with the experience to keep the wheels of agile rolling. Without one, you risk scope creep or loss of momentum.

Kanban, on the other hand, doesn’t require a certificate in Scrum. Since it can be customized to fit the processes of virtually any team or business and is easy for anyone to understand, you can hit the ground running. And updates are released whenever ready—no need to wait for a release milestone like a sprint retrospective.

What’s more, you’ll generate less waste because you get a comprehensive overview of the project sooner (rather than taking it one sprint at a time). Which improves the delivery flow so you can get the results you want from the project faster.

If you’re working in a large or distributed team, pick Kanban.

Scrum is ideal for smaller, (ideally) collocated teams of no more than 10 people.

I’ve seen attempts to scale Scrum to fit larger organizations but wouldn’t recommend it. Though it now transcends industry boundaries, Scrum’s roots are really in software development, which works more seamlessly in the nimbler environments of smaller teams.

Plus, inability to collaborate regularly pretty much defeats the purpose of Scrum. In larger or distributed teams, it’s harder (but not impossible!) to keep daily Scrum meetings efficient.

But Kanban doesn’t have team size limitations.

If you think your priorities might vary over the course of the project, pick Kanban.

With Scrum, your team commits to shipping some small increment of value by the end of every sprint.

But delays happen. One danger of Scrum is that if one release stalls, the whole project might come to a standstill. Each sprint builds on the previous.

In Kanban, activities aren’t tied together like this. Continuous delivery is key. That’s why it works best for projects with lots of incoming requests that vary in priority or size. It’s a parallel circuit: even if one bulb blows out, the electricity keeps on flowing.

So if you’re in a volatile business looking for a methodology that can bend with the winds of your company’s flexible processes, Kanban is for you. Scrum is for projects with scope that doesn’t change much over time.

If you need structure, pick Scrum.

On the other hand, Kanban’s advantage of fluidity can also be its downfall.

Some teams need deadlines. Without them, it’s more likely that tasks will stagnate or take longer than they need to.

So if you’re working on a project that needs to operate under specific roles, procedures, and/or timelines, Scrum is your best bet. It keeps everyone on track. And in case something isn’t working, it gives you the chance to reset to factory settings at the end of the sprint.

If you need more transparency, pick Scrum.

Some agile folks tense up at the mention of “roles” and figure that owning your own area of responsibility must mean working in silos. But don’t worry—Scrum was designed to account for this.

In fact, it was designed to promote more accountability and visibility within the team than you’ll find using other methodologies. What’s great about Scrum is that frequent check-ins are part of the deal. That makes it easier to get everyone on the same page and to collaborate as a fully integrated team. You can keep an eye on what deserves reward and what needs support.

Kanban doesn’t necessarily lack transparency. It’s meant to be visible. But in some cases it might be more challenging to keep track of all those moving parts.

If you value customer-driven development above all else, pick Scrum.

Kanban’s continuous delivery system is well-suited to meeting the changing expectations of customers. If those expectations aren’t being met, your team has multiple opportunities to switch gears during iterations.

But again, some teams need more focus.

And to Scrum teams, customer feedback is everything. The work system is incremental for a reason: the stop-start nature of things provides set opportunities to step back, learn from your customers, and concentrate all your energies on a limited number of viable solutions.

Part of the philosophy of Scrum is shipping value to customers first and foremost, so they are the ones who inform what direction you take next.

And if none of the above matter to you?

Why not try both!

Your decision doesn’t have to be black and white. It’s not uncommon for Scrum teams to adopt Kanban boards for an added layer of visibility, or for Kanban fans to borrow Scrum practices like daily huddles, or for either to pivot back and forth. If your project allows for it, go ahead and build a system of agile features that works for you.

Conclusion

There’s no right or wrong decision here. Maybe instead of Kanban vs Scrum, we should be thinking about this along the lines of Kanban and/or Scrum.

Especially because the evolution of these methodologies continues. Agile teams should always be looking for new ways to leverage them. If that means building your own custom system, more power to you!

Until then, I hope these simple rules help you assess which method to use on a case-by-case basis.

Did I miss anything? If your “what if” wasn’t covered, drop it in the comments.