Kanban system: origins, principles, and PMO adoption for mixed portfolios

What is the Kanban system

The Kanban system is a workflow management framework that combines visual work representation, work-in-progress limits, pull-based task flow, and continuous improvement into a coherent operating model for teams doing knowledge work. It is not a project management methodology in the Scrum sense: Kanban does not prescribe roles, ceremonies, or fixed iterations. What it prescribes is a set of practices that any existing workflow can adopt without restructuring the team, changing job titles, or scheduling new meetings. This is why the Kanban system spread from manufacturing to software and then to marketing, HR, and IT operations: it fits on top of what a team already does.

The system has four core mechanics that operate together. Visualization makes work visible on a shared representation (physical or digital) so everyone sees the same current state. WIP limits cap the amount of work in progress at each workflow stage, forcing the team to finish before starting new items. Pull replaces push: work moves forward only when downstream capacity opens, rather than being pushed by whoever generates it. Flow metrics measure how quickly and predictably work moves through the system, so improvement decisions are made from data rather than opinion. Together these mechanics produce the outcomes Kanban is known for: shorter delivery times, higher throughput, less context switching, and visible bottlenecks that can be fixed rather than tolerated.

Two things Kanban is not: it is not a substitute for planning, and it is not the same as a Kanban board. A team can have a beautiful board and no system, if there are no WIP limits, no flow metrics, and no policies. A team can also run a rigorous Kanban system without a fancy tool, if the workflow is visualized on a whiteboard and the six practices are followed. The system is the discipline; the board is the visual layer that makes the discipline concrete.

The origins: from Toyota to knowledge work

The Kanban system originated in Toyota's manufacturing plants in the late 1940s, developed by industrial engineer Taiichi Ohno as a mechanism for lean production. The Japanese word kanban means visual signal or signboard, and the original kanban cards were physical tokens moving between workstations to signal when parts needed to be replenished. The point was to eliminate the buildup of inventory: instead of pushing components down the line whether they were needed or not, downstream stations pulled components as they consumed them. The result was just-in-time production, dramatically less inventory, and a system that surfaced bottlenecks by making inventory anomalies visible.

Kanban stayed in manufacturing for over half a century before software teams adapted it. In the early 2000s, David Anderson and others recognized that knowledge work has the same fundamental problem manufacturing did: too much work in progress, invisible flow, and no mechanism for teams to see where their delivery bottlenecks actually were. Anderson formalized the Kanban Method for software in 2010, introducing the six practices and the change management principles that let teams adopt Kanban without restructuring. From software the system spread further: IT operations adopted it for incident and change management, marketing agencies for campaign delivery, HR for hiring pipelines, and portfolio-level PMOs for coordinating flow across multiple teams.

The migration matters because the Kanban system's core insight travels across contexts. Whether the work is car parts, software features, or marketing campaigns, the pattern is the same: too much work in progress destroys flow, and visibility plus limits restores it. This is why the system has proven durable while other management fads have not. The mechanics are simple enough to adopt incrementally, and the results are visible fast enough to sustain the adoption.

Kanban system vs. Kanban board: the crucial distinction

The most common confusion in Kanban discussions is treating the board and the system as synonyms. They are not. The Kanban board is a single visual artifact, columns representing workflow stages, cards representing work items. The Kanban system is the complete framework: the board is one component, alongside WIP limits, explicit policies, flow metrics, cadences (regular meetings and reviews), and the six practices. A team can have a Kanban board without a Kanban system, and the difference shows up in the outcomes.

Consider what happens when a team implements only the board. Someone draws columns on a whiteboard or opens a Jira project with a Kanban template. Work items get cards. The team feels more organized because they can see everything. But without WIP limits, the team keeps starting new work whenever priorities shift, and the board fills up with in-progress items that never finish. Without flow metrics, the team has no way to know whether they are improving or stagnating. Without explicit policies, everyone interprets in progress differently, and hand-offs between stages produce constant re-work. The board looks Kanban, but the outcomes remain what they were before.

The full Kanban system adds the layers that convert a visual tool into an operating discipline. WIP limits at each column force the team to finish work before starting new items. Explicit policies define what done means for each column, so hand-offs are predictable. Cycle time and throughput metrics reveal whether the system is actually improving over time. Feedback loops (typically standups, delivery planning meetings, and periodic reviews) surface problems while they are still small. The board is the surface; the system is what happens around it. Getting this distinction right is the difference between a team that runs Kanban and a team that has a Kanban board. Our Kanban workflow guide and Kanban board guide cover the board and its use in depth; this article focuses on the system that wraps around it.

The six practices of a Kanban system

The Kanban Method, as formalized by David Anderson and codified by Kanban University, defines six practices that constitute a Kanban system. These are not sequential steps but concurrent disciplines: mature Kanban teams run all six together, adjusting each as the system matures. Skipping any one of them turns Kanban back into a Kanban board.

Visualize the workflow. Every work item and every stage of the workflow must be visible on a shared representation. This is the board, whether physical or digital. The columns represent workflow stages (typically To Do, In Progress, Review, Done, but customized per team), and the cards represent individual work items with owner, size, and current state. Visualization sounds trivial but transforms behavior: teams that can see all their work stop double-committing to conflicting priorities, and hand-offs become concrete rather than assumed.

Limit work in progress. Each column on the board has a maximum number of items that can occupy it at any time. When the limit is reached, no new items can enter until existing ones finish. WIP limits are the single most powerful practice in Kanban because they force the team to focus on finishing rather than starting. A common starting rule is one to two items per team member per column, tuned downward as the team gets comfortable finishing before starting. The pain of a WIP-limited board is intentional: it makes bottlenecks visible immediately.

Manage flow. Flow is the movement of work through the system, and managing it means actively watching for and removing blockers rather than passively hoping items progress. The team looks at the board daily, identifies items that are not moving, and asks why. Sometimes the answer is a dependency, sometimes a policy problem, sometimes an individual capacity issue. Managing flow is a discipline of intervention, not just observation.

Make policies explicit. Every column on the board has policies that define what done for that column means: what quality bar must be met, what artifacts must be produced, what approvals are required. These policies are written down and visible next to the board, so new team members can understand the workflow without asking, and hand-offs between stages are predictable. Explicit policies are the antidote to the common Kanban failure where each person interprets done differently.

Implement feedback loops. A Kanban system needs regular cadences (meetings and reviews) where the team examines how the system is performing and adjusts it. Common cadences include a daily standup (what moved, what is stuck), a delivery planning meeting (what to pull next), and a periodic operations review (how the system is performing against its metrics). The feedback loops are what convert Kanban from a static workflow visualization into a learning system.

Improve collaboratively, evolve experimentally. Kanban does not prescribe a specific process; it prescribes continuous improvement of whatever process the team has. When a bottleneck appears, the team runs a small experiment to address it, measures the result, and either adopts or rolls back the change. This experimental discipline is what distinguishes mature Kanban from checkbox Kanban.

Core metrics of a Kanban system

Four metrics form the measurement backbone of a Kanban system. Together they answer the questions a PM or PMO analyst actually asks: how fast are we delivering, how predictable is our delivery, are we improving, and where are the bottlenecks.

Cycle time is how long a work item spends actively moving through the workflow, from when the team commits to it (typically when it enters the In Progress column) to when it reaches Done. It is the most useful single metric in Kanban because it correlates directly with what customers experience: how long it takes for their request to be delivered. Cycle time also serves as the primary input to forecasting: a team with a stable median cycle time of five days can commit to five-day delivery ranges with reasonable confidence. Cycle time trending down means the system is improving; trending up means something is wrong.

Lead time is the broader measure, from when a work item is requested to when it is delivered. It includes cycle time plus the waiting period before the team commits to the item. Lead time matters for external stakeholders because it is what they experience from their request until they get value. Cycle time is what the team can control directly; lead time depends on both team performance and the backlog policy that determines how long items wait before commitment.

Throughput is the number of work items completed per unit of time, typically per week. It answers the capacity question: how much work can this team deliver on a sustained basis. Throughput combined with the backlog size gives a rough forecast of when the backlog will be complete. Unlike velocity in Scrum, throughput does not require story point estimating: it is a raw count of items delivered, which makes it comparable across teams and periods without normalization.

The cumulative flow diagram (CFD) is the most visually powerful metric because it shows all work items across all states over time. A healthy CFD has smooth, roughly parallel bands representing each workflow stage. When one band swells while adjacent bands stay narrow, the system has a bottleneck at that stage. When the in progress band grows faster than done, the team is accumulating WIP faster than it can finish, and the WIP limits need to be enforced. The CFD is what a PMO analyst reviews to understand a team's health without needing to attend standups.

Kanban vs. Scrum: which framework to choose

The framework choice between Kanban and Scrum is not about which is better in the abstract; it is about which fits the team's work pattern. Both are Agile approaches, both work well in software and knowledge work, but they optimize for different situations. The PM's job is to pick the one that matches how the team actually operates.

Scrum is best for teams doing predictable, feature-oriented development on a sprint cadence. Work is committed in batches (a sprint), roles are clearly defined (Product Owner, Scrum Master, Development Team), ceremonies are standardized, and the team ships increments at sprint boundaries. This works well when priorities are stable enough for a sprint, when a Product Owner can commit to sprint scope, and when the team benefits from the discipline of iteration boundaries. Our Scrum methodology guide covers the framework in depth.

Kanban is best for teams doing continuous, interrupt-driven, or maintenance-heavy work. Support teams handling incoming tickets, DevOps teams managing infrastructure, marketing teams running rolling campaigns, and IT operations teams handling changes all fit Kanban better than Scrum, because their work does not naturally batch into sprints. Priorities shift daily; some items are urgent, others can wait; there is no meaningful concept of sprint scope because the scope is continuous. Kanban's continuous flow matches how these teams actually work.

The decision matrix is roughly this: use Scrum when work is feature-oriented, priorities are stable within a sprint window, and the team ships releases on a predictable cadence. Use Kanban when work is service-oriented, priorities shift more frequently than sprint length, and the team optimizes for flow rather than release. Use Scrumban (Scrum ceremonies with a Kanban board and WIP limits) when the team needs some discipline of iteration but also needs the flexibility to handle interrupt-driven work.

The choice is not permanent. Mature teams often start with Scrum, evolve to Scrumban as the work pattern shifts, and land on Kanban when interruptions dominate. The framework should serve the team's work, not the other way around.

Adopting a Kanban system in a PMO context

Individual teams can adopt Kanban locally, but scaling it across a PMO is a different problem. Digital.ai's 2024 State of Agile Report found that 71% of organizations use Agile in their software development lifecycle, but only 49% have governance guardrails, meaning most adoptions run without organizational structure. That gap is where PMOs come in. Kanban adoption at the PMO level is less about installing boards and more about establishing the standards, metrics, and coordination that let multiple Kanban teams operate as a portfolio rather than as isolated islands.

Starting small: from workflow visualization to a full system

Kanban adoption is evolutionary, not revolutionary. Kanban University's guidance is explicit: start with what the team does now, and change gradually. A five-step progression works well. Step one is workflow visualization: map the existing process on a board without changing anything else. Step two adds WIP limits based on current volume, tuning downward as the team gets comfortable. Step three adds flow metrics: cycle time and throughput measured weekly. Step four writes down policies for each column so hand-offs become predictable. Step five installs feedback loops: daily standup, weekly operations review, monthly retrospective. By the end the team has a full Kanban system, but the transition happened in small steps rather than a big-bang adoption that would have failed.

Kanban system governance for PMO

The PMO's role in Kanban adoption is to provide standards without micromanagement. Standards include: common flow metrics reported to portfolio level (cycle time, throughput, WIP), consistent board structure across teams so cross-team comparison works, and shared policies for what constitutes done at project level. Micromanagement would be dictating team-level board configurations, WIP limits, or ceremony schedules, which destroys the local optimization Kanban is supposed to provide. The line between the two is where most PMOs struggle. The pragmatic rule: PMO owns portfolio-level metrics and cross-team standards, teams own their local implementation. When a team's cycle time trends worse over multiple weeks, the PMO's job is to ask why, not to prescribe the fix.

Tooling the Kanban system: from whiteboard to portfolio view

Kanban tooling scales in three stages. A physical whiteboard works for small teams in one location: it is high-visibility, low-cost, and enforces WIP limits through physical constraint. Team-level Kanban tools (Jira, Trello, Azure Boards) work for distributed teams: they support digital cards, automated WIP limit enforcement, and metrics generation. Portfolio-level PPM tools work for organizations running multiple Kanban teams alongside non-Kanban projects: they show Kanban work in the same portfolio view as waterfall projects, agile releases, and business initiatives. FlexiProject supports this pattern by making Kanban one of three schedule views alongside a task list view and a Gantt chart view; the team switches between views depending on need, while the PMO sees the same work in a portfolio dashboard alongside non-Agile projects. When teams already use Jira for their Kanban work, the FlexiProject-Jira integration imports their tasks with status, owner, and type preserved, so PMO views stay current without teams changing tools.

FAQ: the Kanban system

What is the difference between Kanban and Scrum?

Scrum is iteration-based: work is committed in sprints (typically two weeks), and the team ships at sprint boundaries. Kanban is continuous flow: work moves through the workflow as capacity allows, without fixed iterations. Scrum prescribes roles (Product Owner, Scrum Master, Development Team) and ceremonies (sprint planning, review, retrospective, daily standup). Kanban prescribes practices (visualize, limit WIP, manage flow, make policies explicit, implement feedback loops, improve collaboratively) but not specific roles or events. Scrum fits predictable feature work; Kanban fits continuous, service-oriented, or interrupt-driven work.

How do you calculate WIP limits?

There is no universal formula; the practical approach is empirical. Start with a limit slightly below current WIP (which is typically too high). A common starting rule is 1 to 2 items per team member per column, or total board WIP of roughly 1.5 times the team size. Reduce the limit gradually as the team gets comfortable finishing before starting. Signs the limit is right: cycle time drops, throughput stays stable or improves, team members focus on fewer things at a time. Signs the limit is too low: throughput drops because the team is starved for work. Signs it is too high: WIP swells and cycle time grows.

Does Kanban require sprints?

No. Kanban is a continuous flow method, not an iteration-based one. Work moves through the workflow whenever capacity opens, without fixed batch boundaries. However, some teams use Kanban with fixed-cadence delivery reviews or planning meetings, which look sprint-like without being true sprints. This is Scrumban: Kanban flow with Scrum-style ceremonies. Pure Kanban does not require sprints; hybrid Kanban may include them by choice.

Can Kanban be used in non-software teams?

Yes. Kanban originated in manufacturing, not software, and its principles apply to any workflow with sequential stages. Marketing agencies use Kanban for campaign delivery, HR teams for hiring pipelines, IT operations for incident and change management, R&D for research projects, and customer support for ticket flow. The mechanics adapt: what in progress means changes across contexts, but visualization, WIP limits, flow, and metrics work the same way. Non-software adoption often has fewer legacy assumptions to unlearn than software adoption.

How do you introduce a Kanban system in an organization?

Start with one team that has an obvious flow problem: too much work in progress, unpredictable delivery, or invisible bottlenecks. Visualize their workflow on a board. Add WIP limits based on current volume, tuned downward over weeks. Add cycle time and throughput measurement. Add explicit policies for each column. Install feedback loops (standup, planning, review). By the time the first team has a working system, other teams see the results and pull the same practices. Organizational Kanban adoption almost never starts with a big-bang rollout; it starts with one team demonstrating the outcomes.

The system, not just the board

The Kanban system is the complete framework around what most people mean when they say Kanban: not just a board, but WIP limits, flow metrics, explicit policies, feedback loops, and six practices that turn a visual tool into an operating discipline. The distinction from a Kanban board matters because most Kanban adoptions plateau at the board layer: teams get the visualization but never install the system, and the flow improvements never materialize. The origins in Toyota manufacturing explain the system's mechanics: too much work in progress destroys flow, visibility plus limits restores it, and the pattern works across contexts from car parts to software features to marketing campaigns. The framework choice between Kanban and Scrum is not a matter of Agile purity but of matching the tool to the team's actual work pattern: Kanban for continuous, service-oriented, interrupt-driven work; Scrum for predictable feature-oriented sprints. PMO adoption requires standards without micromanagement, portfolio-level metrics without dictating team-level configurations, and tooling that scales from team boards to cross-team portfolio views. FlexiProject supports this pattern by making Kanban one of three schedule views alongside a task list view and a Gantt chart view, so teams choose their preferred representation while PMOs see the same work in a portfolio dashboard. A Kanban system done right delivers what the board alone never can: predictable flow, visible bottlenecks, and continuous improvement grounded in metrics. Done wrong, it is just a whiteboard with sticky notes.