Kanban That Keeps Work Moving

Simple rules, visible flow, fewer surprises for teams

Why Kanban Still Works So Well

We’ve all seen the pattern: work starts piling up, priorities change every other day, and somehow everyone is “busy” while the important thing sits in limbo. That’s exactly why kanban still earns its place. It gives us a clear picture of work as it really is, not as we wish it looked in a slide deck.

At its core, kanban is about visualising work, limiting how much we do at once, and improving flow over time. That sounds modest, and that’s part of its charm. We don’t need a dramatic reorg or a three-day offsite with sticky notes and expensive sandwiches. We need a board, a shared understanding of stages, and the discipline to stop starting and start finishing.

The original approach came from manufacturing, but modern teams have made it very much their own. Software, operations, support, content, security—if work moves through stages, kanban can help. The Kanban Guide keeps the principles refreshingly grounded, and Atlassian’s overview gives a decent practical summary without too much theatre.

What we like most is that kanban meets teams where they are. If our process is messy, the board shows us the mess. Painfully, sometimes. But that visibility is useful. Once the work is visible, bottlenecks stop hiding in inboxes, DMs, and “quick calls.” Then we can talk about actual flow, not folklore.

Kanban also plays nicely with reality. New requests arrive. Urgent fixes happen. Teams split time between project work and support. Instead of pretending that chaos doesn’t exist, kanban helps us manage it with clearer rules and fewer heroic rescue missions.

Building A Board People Will Actually Use

A kanban board should reflect how work really moves, not how a process manual says it ought to move. That’s the first trap to avoid. If our board is too neat, too clever, or too detailed, people stop trusting it. Then they stop updating it. Then it becomes office wallpaper with columns.

A good starting point is painfully simple: Backlog, Ready, In Progress, Review, Done. That’s enough for most teams to begin learning. Later, we can add nuance where it helps, such as Blocked, Waiting on Vendor, or Deploying. But every extra column should earn its keep.

The key is defining what each column means. “In Progress” sounds obvious until five people use it five different ways. Is work there when coding starts? When someone picks up a ticket? When we’re halfway through? A short policy for each stage saves endless confusion. Microsoft’s guidance on workflow visualisation is useful here because it shows how little structure we actually need to get started.

Here’s a simple board policy example we might use:

columns:
  - name: Backlog
    policy: "Ideas and requests not yet committed"
  - name: Ready
    policy: "Clearly defined, sized, and eligible to start"
  - name: In Progress
    policy: "Actively being worked on by an owner"
  - name: Review
    policy: "Needs approval, testing, or peer review"
  - name: Done
    policy: "Meets acceptance criteria and requires no further action"

Notice what’s missing: jargon for the sake of it. A board should make work easier to understand in 10 seconds or less. If it needs a tour guide, we’ve probably overcooked it.

The best boards also show blocked work clearly. Hidden blockers are where lead time goes to die. Make them visible, and suddenly conversations get more honest.

WIP Limits: The Rule Teams Resist And Need

If there’s one kanban practice teams push back on first, it’s work-in-progress limits. We get it. Everyone believes their situation is special. “We can’t limit work because everything is urgent.” That’s usually a strong hint that we should limit work.

WIP limits force us to confront a truth we’d rather avoid: multitasking is often just slow motion. The more items we start, the longer they all take. Context switching burns attention, handoffs create waiting, and queues quietly expand until deadlines begin making threatening noises.

A WIP limit is simply a cap on how many items can sit in a given stage. For example, if In Progress has a limit of 4, we don’t pull a fifth item until one of the four moves on. That can feel uncomfortable at first because it exposes under-the-hood problems. Reviews are delayed. Testing is overloaded. Priorities keep changing. Good. Now we can see them.

Little’s Law gives the maths behind this: more items in the system generally means longer wait times. We don’t need to become mathematicians at the whiteboard, but it helps to remember that queues are not harmless. They’re time in disguise.

A simple policy might look like this:

{
  "wip_limits": {
    "Ready": 10,
    "In Progress": 4,
    "Review": 3
  },
  "expedite_rule": "Urgent items may bypass Ready but must be reviewed in daily standup"
}

What happens when a column hits its limit? Ideally, we stop pulling and start helping. That might mean pairing on review, unblocking testing, or clarifying requirements. It’s less glamorous than starting something shiny, but it’s how flow improves.

WIP limits aren’t about control for control’s sake. They’re there to protect delivery. If our board says fifteen things are active, nobody really knows what matters. If it says four, we have a fighting chance.

Service Classes And The Art Of Handling Urgency

One reason teams hesitate with kanban is the fear that urgent work will wreck the board. To be fair, urgent work often does wreck the board—just more quietly when we don’t account for it. Kanban gives us a way to handle urgency without pretending every request deserves flashing lights.

This is where service classes help. We can separate work by how it should flow rather than by who shouts the loudest. A common set is: standard, fixed date, expedite, and intangible. Standard work is normal business. Fixed date work has a deadline. Expedite is truly urgent and should be rare. Intangible work includes improvements that matter but are easy to postpone, like cleanup or technical debt reduction.

The trick is to make the rules explicit. If expedite means “anything from a director,” we don’t have a service class; we have a political weather system. Better to define clear entry criteria. Planview’s explanation of kanban classes of service is a handy reference for this.

We might document policy like this:

[class_of_service]
standard = Default lane, follows normal WIP limits
fixed_date = Prioritised based on deadline risk
expedite = Production incident or severe customer impact only
intangible = Improvements, maintenance, debt reduction

This helps us protect flow for normal work while still making room for the occasional fire. And yes, there will be teams where everything is marked urgent for a few weeks. That’s not a kanban failure; it’s a signal that prioritisation upstream needs help.

When service classes are visible on the board—via swimlanes, card colours, or tags—conversations improve. We stop arguing from instinct and start discussing policy. It’s less dramatic, which is excellent. We’ve had enough drama from production already.

Metrics That Tell Us More Than Velocity Ever Did

Kanban gives us useful metrics without needing estimate theatre. Instead of obsessing over whether a task is three points or five points, we can look at how work actually moves. That shift alone tends to calm teams down.

The three metrics we care about most are cycle time, lead time, and throughput. Cycle time measures how long work takes once started. Lead time measures the full journey from request to completion. Throughput tells us how many items finish in a given period. Together, they show whether the system is flowing or sulking.

A lot of teams skip this because metrics feel like management bait. Fair concern. But the point isn’t to judge individuals; it’s to understand the system. If review time keeps ballooning, that’s not a personal failure by the reviewer. It may mean our review queue is overloaded, our changes are too large, or our criteria are fuzzy.

ActionableAgile’s resources are useful if we want to go deeper on forecasting from flow data. We can also use GitHub’s project documentation or our board tool’s built-in charts as a starting point.

A lightweight metrics file might be as simple as:

metric,definition,goal
cycle_time,Start to Done,Reduce variation
lead_time,Request to Done,Improve predictability
throughput,Items Done per week,Track delivery capacity
blocked_age,Time item remains blocked,Escalate sooner

What matters most is trend, not a single number. One slow ticket proves very little. A recurring pattern proves plenty. Over time, kanban metrics help us make better planning promises because they’re grounded in actual system behaviour. Fancy concept, that.

Running Kanban In DevOps And Support Teams

Kanban fits especially well in DevOps and support-heavy teams because our work rarely arrives in neat sprint-shaped parcels. We deal with incidents, service requests, change work, automation, maintenance, and “just a tiny thing” messages that somehow consume half a day. A fixed batch plan often collapses by Tuesday lunchtime.

With kanban, we can represent these different work types directly. Incidents may have an expedite lane. Standard service requests can follow normal flow. Planned platform work can sit in the same system with separate policies. The board becomes a living view of demand, not just a project tracker pretending support doesn’t exist.

This works best when we define entry and exit criteria well. For example, an incident might not move to Done until a customer update is sent and follow-up actions are logged. Automation work may need documentation before completion. These details sound boring because they are boring, but boring done well is the foundation of reliable operations.

We also need replenishment and review habits. That means regular moments when we decide what enters the board, what gets pulled next, and what needs escalation. The Kanban University resources cover these cadences nicely, though we’d keep the ceremonies lighter than the naming sometimes suggests.

For distributed teams, the board becomes even more valuable. It replaces tribal knowledge with visible status and policy. Instead of asking five people where a request sits, we can just look. That reduces interruption load, which is gold for teams already swimming in alerts and requests.

And perhaps best of all, kanban lets us improve without stopping delivery. We don’t have to freeze the world and redesign everything. We can tune one policy, one limit, one column at a time. That’s usually how sustainable change actually happens.

Common Kanban Mistakes We Keep Seeing

Kanban is simple, but simple doesn’t mean foolproof. Teams can still turn it into a mildly expensive source of confusion if they’re not careful. We’ve seen a few repeat offenders.

The first is treating the board like a task cemetery. Everything goes in, almost nothing comes out, and “Done” becomes a mythical destination discussed in whispers. A board should show active flow, not preserve every request since the invention of Slack. Archive aggressively and keep focus on current work.

The second is skipping policies. If we don’t define what columns mean, how work gets prioritised, or what counts as urgent, people invent their own rules. That’s when chaos puts on a lanyard and starts attending meetings.

Third, teams often add too many columns too early. If our board looks like an airport departure screen, we’ve probably over-modeled the process. Start small. Add structure only where confusion or waiting repeatedly appears.

Fourth, some teams track work but never inspect flow. That’s like installing smoke alarms and then removing the batteries because the beeping is inconvenient. The point of kanban is not merely to visualise work, but to improve how it moves.

Finally, there’s the classic leadership mistake: using kanban metrics to pressure individuals. Once that happens, people game the board, split tickets oddly, or avoid transparency. Trust drains fast. Metrics should help us improve the system, not stage a weekly blame recital.

If we avoid those traps, kanban stays what it should be: a practical tool for clearer priorities, better flow, and fewer hidden queues. No miracle cure, no choreography, just better work management. Frankly, that’s refreshing.

Tags: agilekanban