by Gary Worthington, More Than Monkeys

If you’ve spent any time in software delivery, chances are that you’ve bumped into Kanban. Maybe it was a team board with colourful post-its or someone said “We don’t do Scrum anymore, we just use Kanban.” Maybe it was the mythical “flow-based” team who never seemed to need planning meetings.

But here’s the thing: Kanban isn’t just Scrum Lite. It’s a change management method rooted in systems thinking, evolutionary improvement and, most importantly, limiting work in progress to maximise flow.

What is Kanban?

At its core, Kanban is a pull-based system for managing work. It visualises the flow of work, limits how much can be in progress at once, and encourages continuous improvement.

It’s simple to start with, but powerful in practice, especially for teams dealing with a high rate of change, operational uncertainty, or unclear priorities.

The 6 Core Practices of Kanban:

1. Visualise the work — Use a board to map your workflow. This could be as simple as “To Do / In Progress / Done” (my personal favourite) or something more granular like “Ready / Dev / Code Review / Test / Release”.
2. Limit Work in Progress (WIP) — Each column has a cap. This creates focus, exposes bottlenecks and encourages collaboration. Most digital tools support this out of the box
3. Manage flow — Pay attention to how work moves through the system. Is it steady or stalling?
4. Make process policies explicit — Agree on what “Ready” or “Done” means. Document it. You could borrow the concept of Definition of Done from Scrum
5. Implement feedback loops — Regular retros, service reviews, or stand-ups. Just enough ceremony to reflect and improve.
6. Improve collaboratively, evolve experimentally — Make small changes, grounded in data. Kanban is evolutionary, not revolutionary.

How is Kanban different from Scrum?

Scrum gives you a defined structure: sprints, roles, ceremonies. It’s prescriptive by design. Kanban is the opposite; start with what you do now, and improve it.

Here’s how they differ in practice:

• Cadence
  → Scrum: Work delivered in fixed-length sprints (typically 2 weeks)
  → Kanban: Work flows continuously, pulled when capacity allows
• Roles
  → Scrum: Prescribes defined roles (Product Owner, Scrum Master, Developers)
  → Kanban: No mandatory roles; fits around your existing team structure
• Planning
  → Scrum: Requires Sprint Planning at the start of each cycle
  → Kanban: Pull-based. Work starts when someone has capacity
• Estimation
  → Scrum: Typically uses story points and velocity
  → Kanban: Estimation is optional, instead the focus is on flow metrics
• Commitment
  → Scrum: Teams commit to sprint goals and a specific backlog
  → Kanban: No artificial commitment windows, work progresses when ready
• Metrics
  → Scrum: Burn-down charts and velocity
  → Kanban: Lead time, cycle time, throughput, and WIP limits

Scrum is great when you’re building large, well-scoped features with stable priorities. Kanban is perfect when work arrives unpredictably, priorities shift, or you’re operating in a high-change environment; bugs, BAU work, ops teams, or support squads.

But here’s the fun bit: you can use both. Many teams implement “Scrumban”, a hybrid approach where they keep the roles and ceremonies of Scrum, but switch to flow-based delivery.

Why would you choose Kanban?

• You don’t want or need rigid sprint boundaries.
• Work lands fast and randomly — Think support teams, DevOps, platform squads.
• You have lots of unplanned or interrupt-driven work.
• You want to continuously release — and measure how long things actually take.
• You’re not in a position to radically restructure your process overnight.

CI/CD and Kanban: A Natural Fit

If you’re doing Continuous Integration and Continuous Deployment (CI/CD), Kanban often fits like a glove (just not OJ’s glove).

Scrum introduces artificial release boundaries through sprints. If something’s ready on day three, it still waits until day ten. Kanban doesn’t care: if it’s done, it flows. Ship it.

With CI/CD, code is integrated frequently and deployed automatically. You’re optimising for speed, quality, and confidence. In that environment, fixed-length sprints can feel like unnecessary friction.

Kanban lets you release when ready, not when the calendar tells you to. This unlocks faster feedback, smaller changes, and lower deployment risk. It aligns with modern engineering practices where speed and flow are more important than batch size and commitment.

In short: if you’ve already invested in CI/CD, Kanban helps you get the organisational benefit from the technical capability.

Escape the “Sprint Boundary” Trap

One of the quiet killers of flow in Scrum teams is the mental boundary created by the sprint.

We’ve all heard it:

“I can’t pick that ticket up — I won’t finish it in the sprint.”

It seems logical. Why start something you can’t finish? But this mindset is a byproduct of the sprint commitment structure, not the work itself. It leads to idle hands, cherry-picking of tiny tasks, or starting something half-heartedly just to “stay busy.”

In Kanban, this problem vanishes. There’s no artificial cut-off. If you’ve got capacity, you pull the next highest-priority item. If it gets done tomorrow or next week that is fine. What matters is that work is flowing and you’re not overloading the system.

It shifts the conversation from how much we can commit to in a timeframe to how to keep the system moving sustainably.

Prioritise the Right

In Kanban, we always value the work on the right side of the board more than the work on the left. Why? Because that’s the work closest to delivering value and where we have invested the most effort.

It’s a subtle mindset shift, but a powerful one: finish what you’ve started before pulling new work. Instead of asking, “What can I start next?”, we ask, “What can I help finish?” This encourages collaboration over handoffs and flow over volume. If something’s stuck in Code Review or Testing, jump in and unblock it. Don’t just grab the next ticket from “To Do” because it’s convenient. This helps promote knowledge sharing and breaks down those silos.

Let’s Stop Calling It “Estimation”

Here’s where Kanban really invites a mindset shift.

The word estimation is a loaded one. It implies precision and it suggests we’re trying to predict effort, or timeline, or velocity. It makes people think we’re forecasting, when in reality, we’re just aligning on what needs to be done.

So here’s a better term we should all consider using - Sizing

Its this simple…….

Estimating guesses how long something will take; sizing helps us understand how big or complex it is without inviting false precision.

Sizing Conversations

When we “estimate” a piece of work, the score doesn’t really matter. The point is to talk about it so we can unearth assumptions and explore ambiguity. We should ask “how big is this thing?” in a way that helps the whole team get on the same page.

The size is a signal, but the real value is in the conversation that gets you there.

In Kanban, we still want that shared understanding. We still want to spot risky or bloated work early. A sizing conversation helps you do exactly that, without the pressureof trying to produce a forecast that will be used to beat everyone later.

So yes, you should definitley continue to size your work, but do it to understand the problem, not to guess the outcome.

Forecasts in Kanban come from throughput, cycle time, and real data. Not a number added to a Jira ticket or scribbled on a post-it stuck to a wallboard. (yes, I am old enough to have used physical boards).

How to implement Kanban, without causing chaos

One of Kanban’s best features is that it’s evolutionary. You don’t need to stop what you’re doing. You just need to start where you are and improve from there.

Here’s a sensible way to begin:

Step 1: Visualise your current workflow

Map your team’s actual process. Be honest. If “Code Review” is a regular phase, show it. Don’t fake it for neatness.

Step 2: Add WIP limits

Start by adding soft limits. A good rule of thumb: no more than 2 items per person in progress.

Step 3: Track lead time and cycle time

Start measuring how long things actually take from start to finish, and from when someone starts working on it. Use this to inform conversations about delivery and flow.

Step 4: Run regular retrospectives

You don’t need sprint reviews to reflect. Get together every couple of weeks and look at the board. Where is work getting stuck? Are WIP limits being respected?

Step 5: Evolve your policies

Over time, define your entry and exit criteria for each column. What does “Ready” actually mean? What does “Done” mean?

Final Thoughts

Kanban is deceptively simple. No roles. No ceremonies. No sprints.

But don’t let that fool you. When done well, it surfaces problems Scrum often hides. It encourages flow over output, focus over multitasking, and improvement over adherence to a process.

If your team is drowning in WIP, constantly reacting to new priorities, or tired of planning meetings that feel performative maybe it’s time to give Kanban a go.

And if you’re already doing CI/CD, there’s a good chance Kanban is the delivery model that your tooling has been silently asking for all along.

Because sometimes, the best way to go faster is to do less at once.

Gary Worthington is a software engineer, delivery consultant, and agile coach who helps teams move fast, learn faster, and scale when it matters. He writes about modern engineering, product thinking, and helping teams ship things that matter.

Through his consultancy, More Than Monkeys, Gary helps startups and scaleups improve how they build software — from tech strategy and agile delivery to product validation and team development.

Visit morethanmonkeys.co.uk to learn how we can help you build better, faster.

Follow Gary on LinkedIn for practical insights into engineering leadership, agile delivery, and team performance