Kanban vs Scrum once coding agents do the building
Stefan-Iulian Tesoi · · 6 min read
Choose by how often your priorities change, not by how fast the work gets built. Coding agents shrink most items to hours, which favours Kanban's continuous flow. Scrum's fixed cadence still earns its place where stakeholders need a regular moment to re-decide, and most teams running agents end up with flow plus a weekly planning and review.
The Kanban vs Scrum argument used to be a trade between predictability and responsiveness, with developer time as the scarce resource. A coding agent removes most of that scarcity: the slow parts become writing an item well enough to build and reviewing what came back.
Kanban vs Scrum: which fits a team running agents?
Kanban fits the work, Scrum fits the decisions, and a team running agents usually needs the first more than the second.
The Scrum Guide organises everything around the sprint: a fixed-length event of one month or less, holding Sprint Planning, a 15-minute Daily Scrum, a Sprint Review and a Sprint Retrospective. The Kanban Guide defines no events at all. It asks for a visualised workflow, limits on work in progress, four flow measures (WIP, throughput, work item age and cycle time) and a service level expectation: a forecast of how long one item should take from started to finished, stated with a probability.
| Scrum | Kanban | |
|---|---|---|
| Unit of planning | A sprint with a Sprint Goal | One item, pulled when capacity frees up |
| When priorities can change | At the sprint boundary | Any time before an item starts |
| Main constraint | The time box | The WIP limit |
| Forecast | Velocity across sprints | Service level expectation, such as 85% of items done within two days |
| Required meetings | Four, on a fixed calendar | None |
| What it treats as scarce | Developer time | Flow through the slowest step |
The last row is the one agents change. Developer time is no longer what runs out first, and a method built to ration it rations the wrong thing.
Why do agents push teams towards flow?
Because agents make items small and fast, and a time box is a poor container for many small, fast things.
Three shifts show up within the first few sprints:
- Cycle time drops from days to hours. An item a coding agent picks up in the morning is often waiting for review by lunch, so a two-week batch is half built before the first week ends and the rest becomes padding or an unofficial top-up.
- The bottleneck moves to the edges. Specification before the build and review after it are now the slow steps. A WIP limit on Ready and on In Review protects both; a time box protects neither.
- Work finishes unevenly. An agent can hand back an item at any hour, and the next one should be ready then, not on planning day.
Teams in this position start pulling new items into a running sprint, which is Kanban with a sprint label on it. The pillar post on what changes about sprint planning with AI agents covers why estimates and velocity lose meaning at the same time.
What does a sprint boundary still give you?
A fixed moment when the whole backlog is read and its order re-decided, including by people who are not on the board every day.
A founder, a sales lead or a customer success manager needs a known day on which their request is weighed against everything else. A team without one renegotiates priorities in every chat thread.
Flow optimises each item. A sprint boundary is the one point where someone is obliged to read the backlog as a whole.
A Sprint Goal also says what a batch is for, and that matters for work with a finish line. Our own backlog shows the cost of mixing the two kinds. A daily stream of blog posts was filed under an epic linked to a dated milestone, and the milestone could never reach completion, because there was always another post outstanding. The posts now sit under an epic with no milestone at all: a cadence, not a goal. A stream belongs in flow; something that finishes belongs in a goal.
Four questions that decide it
The continuous flow vs sprints decision comes down to four questions about the team rather than about the method:
- Who changes priorities, and how often? If they are on the board daily, flow absorbs the changes. If they sit outside the team and change their minds in bursts, a fixed review day stops daily renegotiation.
- Is the work a stream or a goal? Bug fixes, dependency updates and content are streams. A launch is a goal. Streams suit flow; goals suit a Sprint Goal or a milestone.
- Where do items wait? Measure work item age per column. If items sit in Ready waiting for specification, or in In Review waiting for a person, a WIP limit on that column does more than any cadence.
- Who needs a forecast, and of what? Velocity answers how much will be done by the sprint's end. A service level expectation answers when one item will be done. Agents make the second easy to measure and the first noisy.
A team that asks "should we switch to Kanban" after adopting agents is usually running Scrumban already: sprints on the calendar, items pulled continuously within them. The useful step is to make that deliberate rather than to choose a side.
How do you switch without losing the useful ceremonies?
Keep the meetings that read the backlog as a whole, and drop the ones that existed to coordinate building.
- Keep a weekly planning, as replenishment. Order the top of the backlog and confirm the next items are specified well enough for an agent to execute.
- Keep the review. It is the day stakeholders see what shipped and re-decide what comes next.
- Keep the retrospective, pointed at rework by cause rather than at speed, as sprint retrospectives with coding agents sets out.
- Replace the daily status round with ten minutes on the items past their age limit.
- Replace the sprint commitment with WIP limits on Ready and In Review, and a service level expectation the team actually measures.
How long the remaining cycle should be is a separate decision, covered in sprint length for teams running agents.
Laimonade runs this hybrid by default. A weekly sprint rolls over every Monday and carries unfinished items forward, and between rollovers agents pull Ready items over MCP. A coding agent can move an item as far as In Review and no further; the sprint workflow lists who can move what.
Frequently asked questions
Is Scrumban a real method or a compromise?
It is a real method with a named origin, though most teams arrive at it by accident. Corey Ladas described Scrumban in 2008 as a way to move a Scrum team towards pull and WIP limits while keeping its cadence. Done deliberately, it keeps planning, review and retrospective on a calendar and runs the board as flow. Done by accident, it keeps the sprint label and nobody owns the WIP limit.
Do Kanban teams still need a retrospective?
Yes, although the Kanban Guide does not require one. Its third practice, improving the workflow, needs a regular point where the team reads its flow measures and changes something. Without one, improvement happens only after a visible failure. A team running agents has more to examine, not less: rework by cause, items that aged out, and specifications that came back wrong.
Can different teams in one organisation use different methods?
Yes, provided they agree on what crosses the boundary between them. A platform team on Kanban and a product team on Scrum work together well when dependencies are written down and each side knows the other's forecast: a service level expectation from one, a sprint end date from the other. The failure is a shared item one team treats as today's work and the other as next sprint's.