6 Core Practices of Kanban

The Kanban Method has six core practices. They’re the operational bones of every mature Kanban implementation — what teams actually do, day in and day out, to keep flow moving and quality intact.

This piece walks through each of the six with the modern context — what each practice really means in a 2026 delivery environment, where teams trip up, and how the practice bends (but doesn’t break) when AI agents and distributed teams enter the picture.

The 6 Core Practices, Modernised

1. Visualise the work.

The one everyone knows. Also the one most teams do badly. Visualising isn’t about drawing an idealised workflow diagram; it’s about making the actual state of the work visible — including the parts you’d rather not see.

Blocked cards. Work waiting on someone else. Cards aging silently in a backlog. Work that got started but was never finished. Mature Kanban boards make these visible, not just the happy-path columns.

Where teams trip up: they visualise the work they want to be doing, not the work that’s actually happening. The columns match the process manual, not the real flow. In 2026, the visualisation also has to survive across distributed teams — which means the digital board is the source of truth, not the meeting where you talk about it.

2. Limit Work in Progress (WIP).

The hardest practice, and the most important. Every team wants to work on more things simultaneously than they can finish; every team pays for that with delays, quality issues, and burnout. WIP limits force the conversation about priorities that most teams avoid.

In 2026, WIP limits matter more, not less — because AI now generates work faster than humans can consume it. Without WIP limits, an AI-augmented team just accelerates its own overload.

The discipline of “no new work until this one moves” is what protects the system. If you take away only one practice from this list, take this one.

3. Manage flow.

Flow is not “how much work got done” — it’s “how smoothly work moves through the system.” Managing flow means measuring cycle time (how long a card takes from start to done), throughput (how many cards move through in a given period), and where work ages (which columns hold cards longest). Teams that manage flow well look at trends, not snapshots.

Where teams trip up: measuring individual utilisation instead of flow. High utilisation is what slow flow looks like from the individual’s perspective — everyone is busy, and nothing is finishing. A well-managed system has some slack; a stalled one has everyone at 100%.

4. Make policies explicit.

The most underrated practice. Every team has policies — what “ready” means, what “done” means, when work can be pulled, who can override a priority, what happens when a card is blocked. In most teams, those policies live in people’s heads. Making them explicit — writing them on the board, in the definitions, in the workflow — forces the tradeoffs to be discussed once, not re-litigated every day.

This is what turns a Kanban board from a task tracker into an operating agreement. It’s also what makes onboarding new team members painless: they can read the policies instead of having to guess them from six months of observation.

5. Implement feedback loops.

Kanban prescribes a specific set of feedback cadences: the daily standup, the replenishment meeting, the delivery planning meeting, the service delivery review, the operations review, the risk review, the strategy review.

Each has a different purpose and a different rhythm. Most teams collapse all of these into one weekly meeting called “the retro” — which is why most retrospectives feel like they don’t accomplish anything.

In 2026, AI-summarised standups can save real time — but they can’t replace the reckoning conversations. Feedback loops require humans doing the work together.

AI is useful for compressing the data-gathering phase; it isn’t a substitute for the decisions those loops are meant to produce.

6. Improve collaboratively, using models and the scientific method.

The hardest practice to sustain, because it requires ongoing curiosity. The practice draws on models from Deming (variation), Goldratt (theory of constraints), and Lean thinking (waste).

What it looks like in real teams: run experiments, measure impact, keep what works, discard what doesn’t.

What most teams do instead: pick a “framework” and freeze it. In 2026, teams that improve collaboratively use AI-surfaced flow analytics as input to the conversation, not as a replacement for human judgement about what to change.

The analytics can tell you what is slowing down; only the team can decide why and what to do about it.

How teams actually apply these today

Three patterns we see in teams that get the six practices right:

• They start with practices 1 and 2, and hold there for three to six months. Visualise + Limit WIP. Trying to run all six from day one usually collapses under its own weight. Once the first two are behavioural habit, add the others.
• They treat practice 4 (explicit policies) as a living document. Policies get reviewed and updated in retrospectives, not set once and forgotten. The policies drift as the work drifts — that’s fine, provided the drift is deliberate.
• They resist the temptation to over-tool early. Physical boards for the first phase. Digital tools once the discipline is running. Every SwiftKanban implementation that stuck long-term followed this sequence.

Where the six practices go wrong

Three common failure modes worth naming:

• “We do Kanban” without WIP limits. This is not Kanban. This is a task board. WIP limits are non-negotiable.
• “Policies” that are aspirational, not actual. If your written definition of “done” doesn’t match what the team accepts as done, you don’t have an explicit policy — you have a document nobody reads.
• Retrospectives that don’t change anything. Practice 6 requires the team to actually try things and measure outcomes. If your retros produce a list of good intentions that nobody acts on, the practice isn’t running.