Agentic Kanban: a working draft for our team
How I am turning the systems and experience in The 20× Developer Playbook into a practice for onboarding more developers and something other teams can try.
By Hamed Taheri. Revised October 19, 2026. Working draft 0.2.0. Each practice is marked running, piloting or planned.
I am developing this to onboard developers into our systems and share our experience with other teams. The records and scripts are in use; repeatable onboarding and team-level gains still need testing. Trials and counterexamples will shape it.
Agile was built for scarce developer hours
Sprints, story points and standups coordinate scarce human development time.
Agents do most of our building. Decisions, review, context and budget remain scarce. More than half the early pipeline runs waited on me (evidence).
It sits on top of the tools you already use
Developers have already picked how one person and one agent build one change: Superpowers, Spec Kit and OpenSpec do that well. None of them covers the team: several people, many agents, shared decisions, a budget, and an honest answer to "what did we actually ship?"
Agentic Kanban is that team layer. Their plan or spec becomes the brief; Agentic Kanban adds three things to it (a budget, the kind of work, and how much the agent may do alone) and runs everything around it.
What replaces what
A person's job: decide, accept, learn
The loop is align, prepare, run, review, accept, learn. People decide what is worth doing and how much risk is acceptable, accept results against evidence, and choose what to change. Agents prepare, build, investigate and review in between. Shipping to production is recorded separately. A coordinator can even run the board overnight under rules the person approved in advance, with a never list and a morning pack; I have tried that for one run of about three days.
The agent capacity is already paid for; the person's job is to turn it into accepted outcomes. With two or three coordinators running, my day was five activities:
Coordinators, each with its own lane
You: five activities, all day
- decidedecideWhat is waiting on me?Decision rounds and asks from the never list
- acceptverifyIs it actually right?Tests, acceptance checks and peer disagreements
- decideprioritizeWhat next, and what not?Grooming, new tasks and work to cut
- learnmonitorWhere is it stuck or burning budget?Blocked lanes, cost and review rounds that do not stop
- learnlearnWhat rule changes?Guidelines, the never list and the weekly review
Right-size every change
Ceremony should match the change. A small fix should not cost a meeting.
| Lane | When | What it takes |
|---|---|---|
| Quick | A small, clear change | No ceremony: build it, open a pull request, done when accepted |
| Task | Normal work | A brief (your tool's plan or spec, plus budget, kind and autonomy), then review |
| Epic | Large or unclear work | A decision round, parts, and one accepted outcome at the end |
Each item also has a kind (build, fix, investigate, review, docs or ops), each with its own proof of done, and links (follow-up, related, blocked by). A handoff is never a new task, so nothing is counted twice.
Four ceremonies
- 1 · dailyMorning briefTop three actions with reasons, then offers: a decision round, or a batch of ready tasks with a cost estimate
- 2 · when three or more decisions waitDecision roundThree or four multiple-choice questions, each option with a why-yes and why-no; answers recorded; tasks return to ready
- 3 · at every stopHandoffA resume point on the task
- 4 · weekly, Friday by defaultWeekly reviewA generated report, then a short retro ending in one or two experiments or a guideline change with an owner
One brief per person per day, not per agent. Overlap checks catch collisions between people; a short weekly sync stays.
Four numbers
- Accepted outcomes, by kind. An epic counts once.
- Cost per accepted task, including failed attempts, reviews and coordination. Unknown stays unknown, never zero.
- Decision wait: how long work waits on a person.
- First-attempt acceptance: how often one attempt was enough.
Pull requests and tickets are not on the list: agents produce those on demand. Most claims about AI productivity are self-reported; these numbers come from records.
Getting started takes three answers
- Which repositories and people?
- How much may agents do alone: read only, draft, act within limits, or ask first?
- What is the budget per task and per week?
Everything else starts from a default. Run it on Personize (in pilot) or on any store that can hold the contract.
What the records show so far
| Running | Piloting | Planned |
|---|---|---|
| Decision rounds, overlap checks, claims, the waiting-on-a-person queue, session handoffs, focused workers with cost caps | Scripted pipelines, the merge gate, one unattended run | Morning brief at session start, weekly review, per-stage cost records, routines, the setup skill, reports |
This comes from my own team: two developers and a few weeks of records. It is a direction backed by a working system, not a proven standard. The next step is a two-week pilot, measured with the four numbers, before anything here is called a result.
Try it
Read https://hamedtaheri.com/playbook/v0.2.0/agent/framework.md.
Compare Agentic Kanban with how our team works today.
Give me a morning brief for me from our current board, and list
which of the four numbers we can already measure. Change nothing yet.
Read the full framework, walk through a worked example, or book a call to join the pilot.