Over the past few years, I have interviewed a lot of Product Owners and Scrum Masters for different roles. Meetups and conferences added more conversations on top of that. After enough of these discussions, a pattern became impossible to ignore.
Every candidate says their team is agile. Every one of them also has the same two complaints, just from opposite directions. Development teams say stakeholders keep adding scope mid sprint. Stakeholders say the development team is not delivering fast enough. Both sides are usually right, and both sides are usually running a process that only resembles Scrum on paper. If you want a closer look at how that stakeholder pressure actually shapes decisions, I wrote about it in The Prism of Priorities.
I have even seen this inside the same organization. One team’s “sprint” is two weeks with a locked backlog. Another team down the hall calls a rolling two week window a sprint but keeps swapping tasks in and out whenever a stakeholder asks. Same company, same job title, two different systems, both labeled Scrum.
This is not a Scrum problem specifically. It is what happens when a team adopts the ceremonies of a framework without adopting the thinking behind it. And from what I have seen across these conversations, Kanban is actually the better starting point for building that thinking, even though most people trust it less.
The Trust Problem With Kanban
Ask a room of developers what they think of Kanban and you will hear some version of “it’s just an endless list with no deadlines.” The assumption is that without sprints, nobody is accountable, and work can sit half done indefinitely.
Ask the stakeholders in that same room and you get a different worry. They want to see progress, they want dates, and an open ended flow feels like it gives them neither.
Both concerns come from the same misunderstanding. Kanban is not the absence of structure. According to Kanban University’s official guide to the method, it replaces sprint boundaries with a different kind of discipline: limits on how much work is allowed in flight at once, and a clear point where work is either committed to or it is not. That discipline is often stricter than what teams call Scrum in practice, it is just enforced differently.
What Kanban Actually Asks You To Do
Strip away the terminology and Kanban asks three things of a team.
- Make the work visible. Most teams already think they do this because they have a board. But a board only helps if it reflects how work actually moves, not an idealized version of it. If work regularly skips steps, gets stuck in review, or bounces back from testing, the board should show that pattern, not hide it behind a tidy three column layout.
- Limit how much is in progress at once. This is the part most teams skip, and it is the part that matters most. When there is no cap on active work, everyone starts more than they can finish. Developers context switch between five half done tickets. QA becomes a bottleneck nobody notices until release week. A WIP limit forces the team to finish something before starting the next thing, which sounds obvious until you try to enforce it against a stakeholder who wants everything started immediately.
- Pull work only when there is room. In Kanban, new work does not get pushed onto a team’s plate because a deadline is approaching. It gets pulled in because capacity opened up. This single shift, from pushing work to pulling it, is what actually protects a team from scope creep. It is not a meeting or a policy document. It is a structural constraint.
None of this requires a new vocabulary to explain to a stakeholder. I usually describe it as a kitchen during service. A good kitchen does not pile every order onto one station at once. Dishes move through stations only when the previous one is clear, and the pass only accepts a plate when it is actually ready to go out. That is a pull system, and most people understand it instantly once you frame it that way.
The Three Numbers That Matter
Kanban tracks progress differently than Scrum’s velocity chart, and this is usually where I lose half the room. So here is the simple version of the three metrics that actually matter.
- Lead time is how long a single item takes from the moment the team commits to it, to the moment it is done. Not from when it was first mentioned in a meeting three months ago. From the actual commitment point.
- Delivery rate is how many items you finish per week or per month. This is what stakeholders actually care about, even if they ask for it using the word “velocity.”
- WIP is simply how much is currently in progress at any given moment. This is the number that predicts the other two. High WIP with no limit almost always means longer lead times and a lower delivery rate, even though it feels like more is happening.
You cannot speed up delivery by starting more things. You speed it up by finishing what is already started. Atlassian has a practical breakdown of how WIP limits work on a board if you want to see the mechanics laid out visually.
The Meetings That Actually Hold This Together
Kanban has its own cadence, and it is lighter than most people expect. Three meetings do almost all the work.
- The daily Kanban meeting is not a status report. It is a look at the board itself, item by item, asking what is blocking flow and what should move next. The difference sounds small but changes the entire tone of the meeting. Instead of “what did you do yesterday,” the question becomes “what is stuck, and why.”
- The team retrospective, run every two weeks or monthly, looks at how the team is working, not just what they shipped. This is close to what Scrum teams already do, and it transfers over without much friction.
- The replenishment meeting, usually weekly or as needed, is where new work gets pulled in from the backlog based on actual available capacity. This is the meeting that protects the WIP limit. Skip it, or run it loosely, and the WIP limit collapses within a few weeks because someone always finds a reason an item is urgent enough to break the rule “just this once.”
That last point is worth sitting with. WIP limits do not fail because teams do not understand them. They fail because nobody defends them under pressure. I have sat in enough of these meetings to know that holding the line on a WIP limit is a leadership skill, not a process detail.
Why Kanban Is A Better Entry Point Into Agile
Scrum asks a team to commit to a fixed batch of work for a fixed period. That is a reasonable idea, but it assumes the team already has some maturity around estimation, scope discipline, and stakeholder management. Most teams starting out do not have that yet, so the sprint commitment becomes a source of stress rather than a source of focus. Scope creep shows up mid sprint, deadlines slip, and the retrospective becomes a blame session instead of a learning one. I ran into a version of this same tension while helping a team move from a short term sprint mindset to a longer term view of their roadmap, and the fix usually starts with the same flow discipline Kanban teaches.
Kanban does not ask for that upfront maturity. It starts with what the team already does and adds visibility and flow control on top of it. There is no ceremony forcing a team to pretend they can predict two weeks of work accurately before they have built the muscle to do that. The WIP limit teaches the underlying agile principle, finish before you start something new, without requiring a sprint commitment the team is not ready to make.
This is also why I tell teams that are struggling with Scrum to try Kanban first, not as a downgrade, but as the foundation. Once a team can reliably manage flow and respect WIP limits, moving to sprint based planning becomes much easier, because the underlying discipline is already there. I laid out the actual step by step version of this transition in Transitioning from Scrum to Kanban, if you want the execution checklist rather than the reasoning behind it.
Adapting Kanban When AI Speeds Up Development
AI assisted development has changed where the actual bottleneck sits, and Kanban boards need to reflect that shift.
A few years ago, the slowest column on most boards was development. Code took time to write. Today, a developer using AI tools can generate a working first draft of a feature in a fraction of the time it used to take. The bottleneck has moved downstream, into review, testing, and validation. I have seen boards where the “In Development” column is nearly always empty and the “Code Review” or “QA” column is permanently over its WIP limit. I wrote about a related side of this shift, why speed without validation creates its own risk, in Three Boys, a Barber, and the Biggest Lie About AI Adoption.
If your WIP limits were set before AI tools changed your team’s development speed, they are probably wrong now. The fix is not to remove the limits, it is to rebalance them. Lower the WIP limit on early stages so work does not pile up faster than review capacity can absorb it. Consider raising capacity, or adding a class of service, for review and validation stages, since that is now the real constraint.
There is a second shift worth naming. Lead time used to be dominated by build time. Now it is increasingly dominated by decision time, how long it takes a human to review, validate, and approve what AI produced. This changes what “flow” means. A fast team in the AI era is not the one that generates code the fastest. It is the one that can validate and ship what gets generated without becoming a bottleneck itself.
I expect this to be one of the more interesting Kanban conversations over the next year or two, because most existing guidance was written before AI changed the shape of the workflow it describes.
A Few Questions Worth Sitting With
If you run a Kanban board today, a few questions are worth asking honestly.
- Do your WIP limits actually get enforced under pressure, or do they bend the first time a stakeholder calls something urgent?
- Has your bottleneck moved since you set up your board, and does your board still reflect where work actually gets stuck?
- Are you measuring delivery rate without watching WIP, and if so, is that giving you a false sense of speed?
I will keep writing about this as I run into more of these situations, especially the part about redesigning boards for AI assisted teams. If you are working through something similar, I would like to hear how your team is handling it.
Tahir Shahzad
Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/
