Learn backend development with my current project: Boot.dev

Kanban vs Scrum – Why Kanban is More Agile

By Lane Wagner on Jan 5, 2021

Agile development is fantastic and has made software development more fun and productive while simultaneously less punitive and slow. While I’m a fan of Agile, I’m not a huge fan of one of its more common interpretations - a Scrum-based workflow. Let’s discuss why I generally prefer a “Kanban” workflow to traditional Scrum. If you’ve read my first article, you’ll know I’m not Scrum’s biggest fan.

What is Agile Development?

From the Agile Manifesto:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

The same authors of the manifesto also have provided the following 12 principles that back it up:

  1. Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Assuming you agree with the majority of these principles, the question is, how do we put them into practice?

Kanban vs Scrum

Kanban and scrum are two of the most popular strategies for putting Agile principles into practice. In my geographic area and perhaps generally, it seems Scrum is, unfortunately, more popular. I don’t think it’s because Scrum is better, but because it makes managers feel better. I’ve already pointed out most of my problems with Scrum here, so instead, in this article, I’ll try to focus on why I believe Kanban methods are more Agile. That said, I think every organization will have different needs depending on culture, preferences, size, etc.

Here are some quick definitions of Scrum and Kanban, but if you’re not familiar with the systems you may want to read up on them in more detail as well.


From the Scrum guide:

A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. In a nutshell, Scrum requires a Scrum Master to foster an environment where:

  1. A Product Owner orders the work for a complex problem into a Product Backlog.

  2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

  3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

  4. Repeat


Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.

Work items are visualized to give participants a view of progress and process, from start to finish—usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.

Comparing the two

Atlassian has a great comparison chart:

Scrum Kanban
Cadence Regular fixed-length sprints (ie, 2 weeks) Continuous flow
Release methodology At the end of each sprint Continuous delivery
Roles Product owner, scrum master, the development team No required roles
Key metrics Velocity Lead time, cycle time, WIP
Change philosophy Teams should not make changes during the sprint. Change can happen at any time

At first glance, Kanban at the very least appears more Agile, but let’s go over some critical points in more detail.

Continuous Flow

As I explain in my criticism of Scrum, Scrum inserts artificial stopping points in the middle of the development lifecycle. The purpose of the sprints is to remind the team to go back and get feedback from customers at the end of each cycle and use that feedback as input to the next cycle.

While feedback is of utmost importance, I’ve found that few teams actually go talk to customers in-between sprints. The underlying incorrect assumption is that getting customer feedback can (or should) be scheduled on a regular cadence. Instead, Kanban takes a more realistic approach and solicits customer feedback constantly without adding stopping points to slow everything down.

In Kanban, we create a task, and we’re always getting customer feedback. The instant the feedback indicates that it’s time to pivot, we just pivot. Sometimes that means throwing away a task or changing its direction completely. That’s okay. Most importantly, we can just get our tasks done, we don’t have to break them down artificially, have meetings to talk about burndowns, or pretend we can estimate their duration using t-shirt sizes.

Continuous Delivery

Kanban places emphasis on continuous integration and delivery. If you’re a fan of DevOps as much as I am, this point is critical. There are many arguments for delivering software as quickly as possible, but here are the key points:

No required roles

Scrum has a product owner, a project manager (dubbed the scrum master), and a development team. Kanban has team members. There isn’t much to say here other than what I’ve already said about hands-off project managers being a mistake.

My main criticism of the way many Scrum teams are organized is that the person who is responsible for timelines often doesn’t have the product knowledge or technical chops to understand what’s going on. They should know why we are working on a certain feature or bug next and ideally even have the technical knowledge to understand why all of this coding stuff is taking so long.


When I work, I don’t take estimates as seriously as most Scrum teams do. I’m not sure if this is a “Kanban vs Scrum” idea – but I’ll give you my personal 2 cents.

Estimates are a necessary component of running a business. We need to have an idea of how soon we can have a feature in the customer’s hands. If we’ve concluded a feature can add $150,000 of revenue each year, that may be great if it takes 2 weeks to get it out the door, but is a horrible time investment if it will take 2 years to complete.

My opinions with estimates are the following: