Why we use Kanban — not Scrum

To produce only what is needed, when it is needed, and in the amount needed.

— Taiichi Ōno, Toyota Motor Company

We use Agile development because it’s proven to be the best way to build good things quickly. But there are many flavours of agile. Two popular methodologies are the much-debated Scrum and Kanban.

If an opinion is worth having, it’s worth putting on the internet, so here are the reasons we favour Kanban. This is not a definitive critique — it’s why it works better for us.

Some would say they’re apples and oranges. But whether they’re tools, frameworks or whatever else, Scrum and Kanban are two ways digital teams get things done. So, we think they’re ripe for comparison.

These are good recaps on Scrum and Kanban if you need them:

What is Scrum?

What is Kanban?

When Scrum makes sense

Scrum is an understandable choice when your organisation values rigidity in certain ways of working, such as:

Aligning team members from different disciplines and experience levels around a unit of work

Demonstrating whole-product improvements at very frequent intervals

Enabling routine forecasting and reporting in a work environment that demands them

The reality of work culture means that some rigidity is almost always needed. When one or more of these elements exist, Scrum — or elements of it – make sense to use.

But beyond that requirement, we advocate for working with as much flexibility as possible.

Why Scrum’s rigidity limits productivity

Scrum is optimised for interdisciplinary teams of mixed experience. It’s a way to get the team pointing in roughly the right direction, then make incremental progress.

The corollary is that it isn’t optimised for the productivity of individuals, and therefore the team as a whole. (We think about productivity in terms of greasing wheels, not cracking whips.)

Scrum assumes that everyone on the team is a generalist — that everyone can contribute significantly to the next sprint’s block of work. But that isn’t always the case.

The work demanded during a sprint can lean on some skills more than others. When deadlines loom, it’s often the most experienced people that crunch to meet goals.

Scrum’s rituals, like sprint planning, daily stand-ups, and retrospectives are intended to keep teams aligned and moving forward. But that rigidity brings inefficiency. When they’re too frequent, rituals can feel like time spent talking about work rather than doing it. So although we’re firm advocates of product demonstrations, we do them as and when there’s something of real value to show.

When your team is made up of specialists, you don’t need a planning meeting every sprint, or a stand-up every day, for people to know what to do. It’s enough to have open lines of communication and meetings when you actually need them.

Why Kanban works for us

Unlike Scrum, Kanban is a continuous flow system. It’s inherently flexible, making it a better fit for teams that value adaptability and focus.

It has its roots in lean manufacturing. It’s one of the 12 pillars of the Toyota Production System, designed to optimise workflow, reduce waste, and improve efficiency by visualising work and limiting work in progress.

The result of its introduction at Toyota was to transform a loss-making company into a leading global brand.1 When a methodology is proven in the trial by fire of real-world mass-production, it’s probably worth a try.

Here’s how Kanban aligns with our approach to collaboration and project delivery.

Building teams around specialisms

Our approach is to build the team around the specialisms the project needs. This allows everyone to use their full skill set and improves quality of work. In our experience, it also enhances work satisfaction.

If a new specialist need arises on a project, we can map it to the right person. If that person doesn’t exist, we can bring a person in without disrupting everyone else.

Limiting work in progress

One of Kanban’s core principles is limiting work in progress (WIP). This prevents overloading the team with more concurrent work than it can reasonably do.

Too much WIP impairs the team’s output in the short term, and burns people out in the long term.

We use Kanban to cap WIP, making sure that everyone can focus on completing tasks before starting new ones. This leads to higher-quality work and fewer bottlenecks.

Putting flexibility first

Kanban doesn’t require rituals, but it doesn’t exclude them either. We still hold stand-ups and board walks to keep everyone aligned, but these happen when we need them rather than being dictated by a framework.

For example, our board walks are an opportunity to discuss blockers, celebrate progress, and reprioritise tasks as needed — and without the pressure of a sprint deadline.

Greater flexibility suits us in a number of ways:

Unbounded discovery work: When we’re exploring new ideas or solving complex problems, Kanban’s flexibility allows us to adapt as we learn.

Motivated teams: Our team is made up of experienced specialists who don’t need micromanagement. Kanban gives them the autonomy to manage their work effectively, helping them stay motivated and productive.

High trust: We cultivate a high-trust environment where the focus is on doing work rather than reporting on it. Kanban supports this by emphasising flow over formality.

Reprioritising: Scrum’s fixed sprints can be too rigid for projects that require us to provide a service or other kinds of support to a client over a period of time. Kanban makes it easier to quickly adapt to changing client priorities.

Results before rituals

We prefer to spend less time on process and more time on being productive. Kanban provides a lightweight, flexible framework that adapts to our needs rather than forcing us into a one-size-fits-all model. We can supplement it with elements of Scrum or, more likely, another framework2 when it helps us — we think of Scrum as a toolkit and Kanban as a way.

If you’re considering your own approach to Agile, we recommend not defaulting to a framework without consideration. Think about what your team needs, what your workflow looks like, and how you can create a process that supports your goals.

By all means experiment, but be wary of clipping your team’s wings by enforcing a suboptimal way of working. Frameworks should bend to team needs rather than vice versa. That’s why Kanban is the right choice for us.

Footnotes

This history of Kanban explores its creation and implementation at Toyota in pleasing detail. ↩

When we need more structure, we tend to use Shape Up rather than Scrum. It follows a cycle of six weeks of building followed by a two-week cooldown to reflect, learn, and plan what’s next. We find this is a sweet spot between exhausting two-week sprints and inflexible quarterly plans, but we’ll talk more about this in a future article. ↩