Kanbanize Now!

01 Aug, 2026

Kanbanize Now!

Or - how we kept running two week sprints while our robots shipped in two hours

A confession before we start

Somewhere right now, a team is holding a sprint planning session to decide what four agents will do over the next fourteen days. The agents finished it during the meeting. Nobody has told the humans, because the humans are busy playing planning poker over a story that has already been implemented twice, in two different branches, neither of which anyone has read.

This is not a story about AI replacing developers. It is a story about a process built around a constraint that no longer exists, defended by people who have forgotten why it was built.

Agile was a response to expensive feedback

Rewind to 2001. Releases were quarterly. Builds were a coffee break. Getting a customer opinion required a formal review with printed documents and at least one person who owned a laser pointer. In that world the two week iteration was genuinely radical - a forcing function that dragged the feedback loop from six months down to fourteen days.

The iteration was never the point. The compression was the point. Sprints were a crutch for organizations that could not yet flow, and everyone quietly agreed to keep using the crutch long after the leg had healed.

Then we did what humans always do with a useful crutch. We standardized it, certified it, scaled it, put it in a framework with a two day training course, and produced an entire professional class whose income depends on the crutch never coming off.

The constraint moved and nobody updated the board

Goldratt's rude little insight was that every system has exactly one binding constraint at a time, and that any improvement made anywhere else is not an improvement. It is a slide.

For twenty years the constraint in software delivery was, roughly speaking, producing correct code. So we optimized furiously around it - better languages, better IDEs, pairing, frameworks, package managers, an entire website of strangers answering questions at three in the morning, and finally a machine that writes the code for us.

Congratulations. You killed the constraint. It did not die, of course. It moved. It now lives in all the places where nobody thought to build a ritual -

• Comprehension - somebody has to actually understand the thing before it goes live
• Verification - is it correct, and how exactly would we know
• Integration - six agents, six branches, one trunk, best of luck to you
• Decision - three plausible implementations, all defensible, one of which you must live with for four years
• Accountability - whose name goes under it when it pages someone at 2 in the morning

None of these got faster. Several got slower, because reading unfamiliar code has always been more expensive than writing familiar code, and we have just industrialized the production of unfamiliar code.

Little's law does not care about your feelings

Cycle time equals work in progress divided by throughput. This is not a philosophy. It is arithmetic, and it is remarkably unimpressed by your transformation programme.

Now hold review capacity constant and multiply generation throughput by ten. Work in progress explodes, because producing work has become nearly free while accepting work has not. Cycle time follows work in progress the way water follows gravity. The board becomes a landfill with swimlanes.

Then look at flow efficiency - the fraction of an item's life during which somebody is genuinely working on it. It was already humiliating before any of this, commonly cited in the region of five to fifteen percent. Now collapse the touch time with agents while leaving every queue, handoff, approval gate and environment wait exactly where it was. Flow efficiency falls toward the low single digits. The work gets done in minutes and delivered in weeks.

You have not built a faster factory. You have built a faster machine that feeds the same warehouse.

Why Kanban specifically, and not because it is fashionable

Kanban is the only mainstream method whose primary object of attention is the queue rather than the commitment. Everything else asks what did we promise. Kanban asks where is it stuck. In an era where the answer changes weekly, that difference is not cosmetic.

• WIP limits - the single most important control mechanism in an age of infinite cheap production. An agent will cheerfully open forty pull requests before breakfast. A WIP limit is the word "no" expressed as an integer.
• Explicit policies - when a machine does the work, the definition of done stops being a poster on a wall and becomes an executable contract. Vague policies plus fast production equals fast garbage.
• Aging WIP - the item that has been sitting in review for nine days is the story. It is always the story. It is never the burndown.
• Cumulative flow diagrams - a widening band means a queue is forming, and you can see it days before anybody feels it in their calendar.
• Continuous flow - no artificial batch boundary that turns a two hour delay into a two week delay because it missed the cutoff.
• Pull instead of push - work enters a stage only when that stage has capacity, which is the precise opposite of how agent orchestration behaves by default.

Kanban is, stripped of the vocabulary, a bottleneck detector with a decent user interface. In agentic delivery the bottleneck relocates constantly. A method that finds it continuously beats a method that inspects it every second Friday afternoon in a room with biscuits.

The ceremonies, audited without mercy

Sprint planning - a batching ritual answering the question "what can we commit to for two weeks" in a world where the answer changes by lunchtime. Replace it with replenishment. Short, frequent, pull based, boring in the best way.

Story points - a proxy for human effort and human uncertainty. Agent effort is close to zero and agent uncertainty does not arrive in Fibonacci numbers. Measure your actual cycle time distribution and forecast probabilistically from it. More accurate, and it requires zero group therapy.

Velocity - a metric teams learned to inflate the moment it was used to judge them, now upgraded into a measure of how much unreviewed material you generated this fortnight. A landfill also has excellent velocity.

The daily standup - keep it, but walk the board from right to left instead of person to person. Nobody needs to hear what you did yesterday. Everybody needs to see what is stuck, oldest item first.

The retrospective - keep it, sincerely. But bring flow data or do not bother. Feelings plus a cumulative flow diagram is insight. Feelings alone is a support group with a whiteboard.

The burndown chart - a beautifully rendered graph of a promise that should never have been made.

The steelman, because zealotry is also a bottleneck

Cadence is not the enemy. Humans need rhythm. A regular heartbeat for alignment and reflection is valuable, and plenty of teams flow beautifully inside sprints because they treat the sprint as a heartbeat rather than a batch. If that is you, carry on, you were never the problem.

Equally, Kanban without WIP limits is just a to do list with extra columns and better branding. Half the teams claiming to have "moved to Kanban" have actually moved to having no policies, no limits and no discipline, which is not flow. It is chaos with magnets.

And Scrum was never really the problem. Cargo culted Scrum was. An organization capable of turning a lightweight framework into a compliance regime will do exactly the same thing to Kanban within two quarters, complete with a maturity model and a dashboard nobody reads. The board is not the fix. The willingness to stop starting and start finishing is the fix.

Flow metrics are gameable too. Slice work finely enough and throughput looks magnificent while absolutely nothing reaches a customer.

What to actually do on Monday morning

1. Map the real workflow, including the embarrassing parts - waiting for the security review, waiting for the one person who understands the auth service, waiting for an environment that exists mostly as a rumour.
2. Put agent generated work on the same board as human work. If it is not visible it is not managed, it is merely accumulating.
3. Set WIP limits per stage, and set them deliberately too tight. The discomfort is the diagnostic.
4. Create an explicit review and verification stage with its own hard limit. This is your new constraint. Treat it with the respect you used to give the sprint goal.
5. Instrument four numbers - cycle time, work in progress age, throughput, flow efficiency. That is the whole dashboard. Delete the rest.
6. Attack the oldest item every single day before anyone is allowed to start anything new.
7. Re-find the bottleneck every month, because it will have moved while you were admiring the previous one.

The uncomfortable part at the end

If the binding constraint is now comprehension, verification and trust, then the highest leverage investment available to you is not another agent licence. It is automated tests you actually believe, smaller changes, faster pipelines, real observability, and the ruthless deletion of approval steps performed by people who are demonstrably not reading anything.

Buying more generation capacity while your constraint sits downstream is the industrial equivalent of hiring nine more chefs for a restaurant with one waiter. The kitchen becomes tremendously busy. The food gets cold in precisely the same place it always did.

Stop starting. Start finishing. Kanbanize now, or spend the rest of the decade explaining to a machine why its work is waiting on a ceremony scheduled for Thursday.