Kanban can run bad. Not straying away from being a Kanban, but running straight into a strangling mess.
That’s the part people miss. Kanban doesn’t just let bad work through. It produces it.
A card that fragments the system looks the same as a card that fits it. Both flow. Both get pulled. Both move across the board to Done.
That’s not a failure of execution. It’s what the board is.
What the board actually knows
A Kanban board knows one thing about a card: where it is. A column tells you position in the flow.
It doesn’t tell you what the card needs. It doesn’t tell you what has to be true before the card can be finished. Readiness isn’t a column.
So a card at the top of the queue looks ready. It’s in the right place. Nothing on the board says otherwise.
That’s the first problem, and it isn’t visible yet.
Where dependencies come from
Suppose the card isn’t ready. The API it needs hasn’t shipped. The component it depends on is still in design.
How does the board find out? It doesn’t. The developer does.
They pull the card, start work, and halfway through discover the dependency isn’t satisfied. Then they add a marker. The board records the collision.
That’s how Kanban learns about dependencies. By running into them.
Which means a marker is a scar, not a forecast. It tells you where a barrier was. It doesn’t tell you where one will be — because predicting a dependency requires knowing that card A needs card B before anyone works on either. Kanban has no model of that. It has cards and columns.
So every marker is a record of damage already done. The board shows where you were cut. Not where you’ll be cut next.
And a marker doesn’t enforce anything either. Even when the dependency is known and marked, nothing on the board stops the dependent card from being pulled first. A developer might see the marker and hold off — but that’s a judgment call, not a rule. The board shows the relationship. It doesn’t act on it.
And the queue isn’t ordered to help. In Kanban, the queue is ranked by priority — value, cost of delay, business importance. Not by dependency. The dependency is marked so a human can notice it. Whether the order respects the dependency is left to whoever pulls the card. A judgment call, not a rule, and not something the board enforces.
So order is still whatever the queue says. A well-defined card can be worked before the card it needs — both pieces sound, both belonging to real components, both with a clean interface between them — and the work still happens in the wrong order.
In a designed schedule, the dependency determines the order. The dependent task isn’t available until its prerequisite is satisfied. On a Kanban board, availability comes from the queue. And the queue doesn’t know what depends on what.
What that costs
A card sits at the top of the queue. Position says it’s ready. The board has nothing to say otherwise. So a developer pulls it.
Then they hit the dependency. Work stops. Half-done. The card goes back, or sits in “In Progress” marked blocked.
Pull was supposed to mean “work starts when capacity is available.” But capacity isn’t the only constraint. Readiness is. And the board doesn’t model readiness.
So the work is wasted — and it doesn’t come back with the card.
The first developer can leave notes. They can record what they found and where they stopped. But a record isn’t a transfer of understanding. The next person still has to reconstruct what the code actually is, and the reconstruction can be wrong — the note says what the first person thought, not what they found.
Or they skip the notes and start fresh. Either way, the work of the first developer doesn’t carry forward. The cost isn’t one blocked card. It’s the same work, done again — and it repeats every time the card cycles.
Why the card couldn’t have prevented it
You might think a better-written card would solve this. It can’t.
A card is a work item. On a computer it can hold anything — a description, attachments, checklists, links, history. That’s not the limitation.
The limitation is that it holds the task, not the task’s place. It can say what to build. It can’t say where the piece sits in the structure, which boundaries it crosses, or what depends on it — because that information was never designed. There’s nothing to write down.
So whoever pulls the card has to imagine the rest. They read the description, look at the codebase, and construct a picture of what the task really is.
That picture can’t be perfect, because the information isn’t there. Something is always missed — an interface detail, a boundary that shouldn’t be crossed, an output that belongs somewhere else.
And this is where it stops being about one card.
Why the decisions don’t add up
A Kanban team is loosely coupled. Each person pulls a card and makes their own decisions:
— Should I add an error path here, or let it throw?
— Should I validate this data before using it?
— Does this function need a batch interface, or is simple enough?
The answer depends on who you ask. And it can’t be consistent, because no one holds the complete picture. The board doesn’t hold it. The card doesn’t hold it. Each developer holds a fragment.
Every one of those decisions is locally reasonable. Together, they don’t add up.
The premise Kanban borrows that software doesn’t have
There’s a related ideal in Kanban writing: any developer should be able to pick up any card.
It works on a factory line, where every step is the same and every worker can perform it. Software has neither property. A card touching the billing system and a card touching the rendering layer require different knowledge, and no team has uniform coverage of both.
So the ideal doesn’t produce flexibility. It produces rotation — and rotation is how expertise gets thin. The person who deeply knows a component is the person best placed to change it. Moving work away from them doesn’t spread knowledge. It spreads the absence of it.
Kanban asks for a team where anyone can work anything. Software teams don’t have that, and trying to build it makes them worse at the things that matter.
Impractical premises of Kanban
Kanban was built for a factory, and some of its premises don’t survive the move to software. These are the ones that fail — and they’re the reason it runs bad.
Work repeats.
A factory produces the same part again and again. The card can stay minimal because the work is already known. Software produces a different system every time, and no two cards are the same work. This premise fails, and everything downstream of it fails with it.
Any worker can do any job.
A factory line is standardized, and every worker is trained to the standard. Software requires domain knowledge, technical specialization, and familiarity with specific code. This premise fails, and the attempt to enforce it produces rotation instead of flexibility.
Items are small and roughly uniform.
A card’s work at Toyota was measured in hours, and every card was roughly the same size. Software work ranges from a config change to a multi-week integration. Sizes vary so widely that summing them produces no meaningful plan.
The queue can be ordered by dependency.
The queue is ranked by priority — value, cost of delay, business importance. Dependencies are marked visually, so a human can notice them. But nothing orders the queue by what must come before what. Whether the order respects the dependencies depends on who pulls the card and whether they looked.
A board can manage the work.
This is the one that fails hardest, because it’s the premise the rest depend on. A board can display work. It cannot manage it — it doesn’t know readiness, it doesn’t model dependencies, and it can’t enforce order. At Toyota, the surrounding system did the managing: standardized work, leveled production, a line anyone could stop. Software adopted the board and left the system behind.
Why the failure doesn’t surface
By now you’d expect something to break. It doesn’t.
When the dependency is discovered late, the work doesn’t reset. The card goes back on the board. Development continues. The release date slips.
And the missing piece doesn’t get designed. Either the team makes it visible — a blocker card, a dependency ticket, a comment — or it may be mentioned in standup and worked around, if it’s mentioned at all. Either way, the piece has no standing. It isn’t a requirement, because it does not tell you what to build. It isn’t a design decision, because no one decided it. It’s just something in the way.
The structure is still incomplete. The piece that was missing is still missing. The board knows about it now — a marker on a card, added after someone hit it. What the board can’t do is tell you it’s missing before it costs you.
Which means the board can’t tell good work from bad
Here’s where it lands.
If the work was decomposed well — pieces aligned with the system’s components, dependencies clean — the board still looks the same. Cards flow. Work completes. And nothing guarantees the dependent task is worked after the task it depends on. A card can be pulled first because it’s next in the queue, not because its prerequisite is done.
If the work was decomposed badly — pieces cut by size or effort, interfaces undefined — the board looks exactly the same.
Same appearance. Same flow. Same green board.
The board can’t tell the difference, because the difference lives in the structure, and the board doesn’t show structure. It shows position.
What that produces over time
So Kanban isn’t a method for producing good work. It’s a mechanism for moving work. And it moves whatever it’s given.
The bad work doesn’t announce itself. It accumulates. In interfaces never designed to fit. In dependencies discovered by collision instead of designed in advance. In a hundred small decisions — error handling, validation, interface shape — each reasonable on its own, none consistent with the others. In debt nobody recorded because no column said “this doesn’t belong.”
By the time it’s visible, it isn’t visible on the board. It’s visible in the maintenance cost — the features that take longer than they should, the fixes that touch more than they should, the engineers who leave because the codebase has become impossible to hold in their heads.
That’s the strangling. Not a collapse. A slow closing of the space in which the work can still be done.
And that’s why it’s the wrong tool
Nothing here is a bug. Kanban does exactly what it was built to do: it makes work visible and lets it flow.
But the board shows work items, not the structure they belong to. It can’t tell readiness. It can’t foresee a dependency. It can’t enforce an order. It can’t hold a decision that outlives a card. So it moves bad work just as smoothly as good work — and shows you a green board the whole way.
That’s not a malfunction. That’s the design.
Which means the problem isn’t how Kanban is used. It’s what Kanban is. If your team wants to be efficient — if you want the work to add up, the interfaces to hold, and the system to survive its own growth — Kanban doesn’t give you the means to get there. It gives you a board, and it tells you the work is moving.
The work can move all the way to unmaintainable.
Teams that want to be efficient need structure: components with boundaries, dependencies made explicit, readiness known before a card is pulled, and decisions written into the structure rather than held in someone’s head.
Kanban offers none of that. It never claimed to.
So the choice isn’t whether Kanban is executed well. It’s whether a board that can only show position is enough for the work you’re doing. For any project team that wants to be efficient, it isn’t.
Related: