Back to Basics with Kanban

20 Jul

Kanban is one of the simplest agile methods to start, which is exactly why it's often misunderstood. Almost every team that puts tickets on a board says they're "doing Kanban." But are they really?

Too often we see teams get busy visualising the work and stop there. The board goes up, but the limits never come, the flow never gets measured, and nothing about how the team actually works ever changes.

That's why it helps to go back to basics.

We've created a simple cheat sheet for our clients that captures the essence of Kanban's core practices in plain language. This is a way to spark conversations in teams about whether they're truly living the intent of Kanban, or just running a to-do list with extra columns.

Where it comes from

Kanban is a Japanese word for signal card, borrowed from Lean manufacturing where limiting work in progress helped Toyota avoid costly excess inventory. David Anderson adapted the idea for knowledge work in the mid-2000s, and it's grown into one of the simplest ways for a team to get started with agile. David and Andy Carmichael’s Essential Kanban Condensed is well worth a read.

Two of Anderson's original principles come up constantly in our conversations with clients and are key to getting started.

Start with what you do now - map your current workflow before you touch it. Kanban doesn't ask you to redesign your process to adopt it, it asks you to see the process you already have.
Respect the current roles and responsibilities - no new titles, no restructure, no sweeping change on day one. The team keeps its shape. What changes is how visible and how disciplined the work becomes.

That's also why Kanban tends to land well with teams that are wary of change, long-standing support teams and government agencies included.

Continuous Flow

Unlike a Sprint, Kanban has no fixed start, middle or close. Work flows continuously through the board, one piece pulled at a time, with the four principles operating together and feeding back into each other on an ongoing loop.

Kanban is built on four principles. They build on each other, so most teams start with the first and only really feel the benefit once they have worked through all four.

1. Visualise the Work

Purpose: make the work and the process it moves through visible to everyone.

Set your start and end points by beginning the board where work first enters your team and ending it where you hand work over, ideally through to production.
Map the steps between using Story Mapping: Making Work Visible to surface how work really flows, not how you assume it flows.
Make the policies explicit by agreeing what in progress and done actually mean for every column, written down, not just understood in someone's head. This is Kanban's fourth practice hiding in plain sight, and it's the one teams skip most.
Size the tickets to your rhythm using Relative Sizing: Estimating Without the Pain so a daily board shows daily progress.

2. Limit Work in Progress

Purpose: turn a push system into a pull system by capping how much work is in flight.

Set a limit and mean it rather than treating it as a suggestion.
Read the signal when you hit your limit, since it is information, not failure.
Swarm the problem by helping a stuck ticket move instead of starting a new one.
Adjust deliberately by fixing the underlying issue before you raise the number.

3. Manage the Flow

Purpose: answer one question honestly, when will this be done.

Track the cumulative flow to see work in progress at every stage over time.
Watch your lead time from when work starts to when it is done.
Chase the bottlenecks that the flow data points you toward.
Treat blockers as information with a sticker and a reason, not a permanent column.

4. Keep Improving

Purpose: use what the flow is telling you to make small, evolutionary changes.

Read the data from your cumulative flow diagram and your blockers.
Make it everyone's job since improvement in Kanban is a leadership activity, not a management one.
Keep changes small so the team keeps trusting the process.
Prioritise the improvements using Brutal Prioritisation: Finding the Real Musts, since not every idea deserves attention at once.

Why it matters

Kanban does not ask a team to change who they are. It asks them to see their work honestly and finish more of what they start.

Kanban tends to shine in the Clear and Complicated domains, where the work is well understood and arrives as a steady stream rather than needing to be discovered. Scrum earns its keep more in the Complex domain, where the work has to be probed and sensed as you go. Most teams end up living in more than one domain at once, which is exactly why it's worth knowing both. Our Cynefin RAFT: Matching your approach to the work walks through all four domains in more depth once you're ready to go deeper.