Kanban and Scaling Agile

Beyond Scrum

Scrum is the most recognized agile framework in project management, but recognition is not the same as universality. A team building software features in two-week sprints benefits enormously from sprint planning, daily standups, reviews, and retrospectives. That same structure imposed on an IT support team handling a queue of unpredictable tickets creates friction instead of flow. The framework no longer matches the work, and when the framework does not match the work, the ceremonies become overhead rather than value.

Understanding why Scrum sometimes fails requires understanding what it was designed for. Scrum assumes work can be grouped into chunks, planned at the start of a sprint, and delivered as a batch by the sprint's end. That assumption holds for product development, where features are discrete and releasable in defined increments. It does not hold for teams managing continuous demand: operations, support, maintenance, or any environment where new requests arrive faster than any sprint cadence can absorb them. When you force batch delivery onto continuous demand, you end up with artificially delayed responses (items waiting for the next sprint to start), artificially full sprint backlogs (commitments that cannot account for tomorrow's incidents), and frustrated teams running ceremonies that do not reflect how their work actually arrives.

Kanban offers a different organizing principle, and its origins matter. Toyota developed it in the 1940s as a scheduling system for manufacturing, using physical cards (the word "kanban" means card or signboard in Japanese) to signal when parts needed replenishment along an assembly line. The goal was to produce exactly what was needed, when it was needed, without accumulating inventory that would sit idle or go to waste. David Anderson adapted these principles to knowledge work in the mid-2000s, recognizing that information workers face an analogous problem: too much work in flight, invisible bottlenecks, and a persistent tendency to start new work before finishing what is already in progress. The adaptation preserved the core insight from manufacturing: make the work visible, limit what is in progress, and let the system pull new work only when there is genuine capacity to handle it. That idea, simple in principle and counterintuitive in practice, is what separates Kanban from every other agile approach.

Kanban: Managing Flow

A Kanban board visualizes the workflow from the moment a request arrives to the moment it is complete. At its simplest, the board has three columns: To Do, In Progress, and Done. Work items (represented as cards, either physical sticky notes or digital equivalents in tools like Jira, Trello, or Azure Boards) move left to right as they progress through the stages. More complex workflows add columns to reflect the actual stages of work: Backlog, Ready for Development, In Development, In Review, In Testing, Deployment Queued, Done. The column structure should mirror how work actually moves through the team, not how someone wishes it would move. When the board does not reflect reality, it loses its diagnostic value. When it does reflect reality, a single glance tells you more than a thirty-minute status meeting.

The mechanism that makes Kanban work is the WIP limit. Each In Progress stage carries a maximum number of cards allowed at once, and that limit is enforced. If the In Progress column has a WIP limit of four and four cards are already there, no new card can enter that column until one moves forward to the next stage. This is not a soft guideline or a best-effort target. The limit is a hard constraint, and its purpose is to force the team to resolve what is already in flight before taking on more. Real Kanban systems also define explicit policies for exception cases: a production outage or regulatory deadline may bypass the standard WIP limit, but only under a rule the team agrees to in advance, not as informal rule-breaking. When a team member cannot pull new work because a column is at capacity, the correct response is to look at what is blocking items in that column and help move them forward, not to start something else to stay busy. That redirection of effort is exactly what the WIP limit is designed to produce.

The "stop starting, start finishing" principle captures why this matters. Consider two scenarios. In the first, a team has ten items all currently in progress. Each team member is working on something, switching between tasks, responding to questions about three different items simultaneously. Nothing is completing. Work in flight accumulates. In the second scenario, the same team finishes two items completely before starting two more. Two items reach Done. Value is delivered. The team's attention is less fragmented. The second scenario produces better outcomes with less cognitive cost, and WIP limits are the mechanism that makes the second scenario the default rather than the exception.

The visibility effect is equally powerful. A Kanban board with cards piling up in one column reveals a bottleneck. If ten cards are sitting in the Testing column because there are only two testers and both are occupied, that pile is a visible signal that the team has a capacity problem in testing. The board does not fix the problem, but it makes the problem impossible to ignore or explain away. Teams that do not use Kanban tend to describe this situation as "we are moving quickly, just waiting on testing." Teams using Kanban see exactly how many items are waiting, how long they have been waiting, and where in the workflow the constraint lives. That visibility changes the conversation from vague frustration to specific, solvable problem identification.

Three metrics tell you whether the system is actually healthy. Cycle time measures how long a single item takes from the moment work starts to the moment it is done. Throughput counts how many items complete in a given week. Work item age tracks how long an active item has been in progress without finishing. Together, these three numbers give teams a concrete, measurable picture of flow rather than relying on gut feel about whether things are moving.

Scrum vs. Kanban: When to Use Which

The choice between Scrum and Kanban is not a values question or a philosophical preference. It is a structural question about the shape of the work. Scrum fits teams where work arrives in identifiable chunks that can be planned, estimated, and committed to over a fixed period. A software product team building a set of user stories for a customer-facing feature benefits from sprint planning because the features are discrete, development takes days to weeks, and customers expect releases at regular intervals. The sprint commitment creates accountability and predictability. Sprint reviews give teams a natural delivery moment. Retrospectives build a cadence of continuous improvement. All of that works because the work itself is shaped to fit it.

Kanban fits teams where work arrives continuously and cannot be grouped into batches without distorting the workflow. Consider an IT helpdesk receiving service requests, an operations team managing infrastructure incidents, or a maintenance team handling bug reports and small enhancement requests alongside production issues. None of these teams can tell a stakeholder "we will look at that in the next sprint." The work is urgent, the demand is unpredictable, and the value of agility is in responding quickly rather than in planning comprehensively. Kanban lets a team take a new item the moment capacity opens, route it through a defined workflow, and complete it without waiting for a sprint boundary. For this type of work, Kanban is not just a preference: it is the structurally correct choice.

Many teams find that neither pure Scrum nor pure Kanban fits perfectly, and a hybrid approach called Scrumban fills that gap. Scrumban borrows the cadence elements from Scrum (daily standups, regular retrospectives, a prioritized backlog) while dropping the sprint commitment structure and adopting Kanban's WIP limits and flow-based tracking. Teams using Scrumban work continuously rather than in sprints, pulling from the backlog when capacity opens rather than committing to a sprint's worth of work at a planning meeting. This combination suits teams transitioning between approaches, teams managing both planned feature development and unpredictable operational support, and teams that found Scrum's sprint overhead too high but still benefit from regular retrospectives and structured backlogs.

The table above is a decision-support tool, not a verdict. Real teams are not clean archetypes. A team that is mostly building features but also handles a steady stream of support requests might run Scrum for the feature work and a separate Kanban lane for support. A team that started with Kanban and wants to add more structure might introduce sprint reviews without abandoning flow-based tracking. The frameworks are flexible enough to accommodate hybrid approaches; the goal is to let the structure serve the work, not force the work to serve the structure.

Scaling Agile Across Multiple Teams

A single Scrum or Kanban team works well when one team can deliver the product. Most enterprise products require multiple teams. A company building a complex software platform might have eight, fifteen, or fifty development teams all working on different components of the same system. The agile principles that make a single team effective (self-organization, fast feedback, adaptive planning) do not automatically extend to fifty teams. Without deliberate coordination, fifty agile teams produce fifty independently moving parts that do not integrate into a coherent product. Scaling frameworks exist to solve this coordination problem without abandoning the team-level agility that makes each team productive.

SAFe, the Scaled Agile Framework, is the most widely adopted scaling approach in enterprise organizations. SAFe organizes multiple Scrum or Kanban teams into a structure called an Agile Release Train (ART). The ART is not a team; it is a group of teams (typically five to twelve) that plan together, deliver together, and share a common product vision. The coordinating event is PI Planning: a two-day event held every eight to twelve weeks where every team in the ART gathers (in person or virtually) to plan the next Program Increment together. Teams plan their own work, then spend significant time identifying cross-team dependencies. If Team A's feature requires an API from Team B, both teams see that dependency on a shared board and make explicit commitments about sequencing. At the end of PI Planning, the ART has a set of PI Objectives: team-level and ART-level commitments for the next eight to twelve weeks. This gives program managers the long-horizon visibility that traditional project planning provides, while preserving the team's ability to adapt within each sprint during the PI.

SAFe is not the only scaling approach, and for some organizations it is more structure than they need. LeSS (Large-Scale Scrum) takes a deliberately minimal approach: apply standard Scrum to multiple teams with as little additional structure as possible. In LeSS, multiple teams share a single Product Backlog and a single Product Owner, attend a shared Sprint Review, and coordinate through direct team-to-team communication rather than through coordination roles. LeSS works well when the product is genuinely integrated (all teams working on one codebase) and the coordination cost is low enough to manage through team discipline rather than formal structure. Nexus takes a middle path: it adds a Nexus Integration Team to a group of Scrum teams to own the problem of cross-team integration and dependency management. The Nexus Integration Team does not manage the other teams; it manages the integration work that falls between them.

The Spotify model deserves mention as an influence on how many technology organizations think about team structure, even though Spotify itself has moved beyond the model and it was never intended as a framework for adoption. It introduced vocabulary (squads, tribes, chapters, guilds) that describes how to organize people into teams (squads) and how to keep expertise connected across teams (chapters for discipline groups, guilds for communities of practice). Its practical influence is that many organizations now think about how to connect engineers across teams who share a discipline, even when those teams work on different products. Whether they label it a chapter or a community of practice, the underlying problem (how do we keep our Python developers connected to each other when they are distributed across twelve different squads?) is real, and the Spotify model gave it language.

Scaling frameworks solve real coordination problems, but they introduce real coordination costs. A set of teams that could deliver a product through good communication and a shared backlog does not need SAFe. Imposing SAFe on three teams that work well together adds PI Planning overhead, Release Train Engineer roles, and program-level ceremonies that consume time without producing proportionate coordination value. The decision to scale should follow an honest diagnosis: are teams failing to coordinate, missing cross-team dependencies, or delivering components that do not integrate? If yes, a scaling framework addresses a real problem. If teams are coordinating well and the only driver for scaling is organizational preference for named frameworks, the overhead is likely to outweigh the benefit.

Choosing the Right Approach

The question project managers face in agile environments is not which framework is theoretically best. It is which approach fits the actual conditions: the type of work, the maturity of the team, the coordination demands of the product, and the tolerance of the organization for experimentation. Getting that diagnosis right requires understanding what each framework was designed to solve. Scrum solves the problem of discrete, iterative delivery for teams that benefit from planning and commitment cadences. Kanban solves the problem of continuous flow for teams managing unpredictable demand. SAFe and similar frameworks solve the problem of coordination across multiple teams that would otherwise deliver incompatible outputs. When the diagnosis is accurate, the framework fits. When it is not, teams spend energy on ceremonies that do not serve the work.

The choice is also not permanent. Teams experiment, learn, and adjust. A team that started with Scrum and found the sprint planning overhead too high might shift to Kanban or Scrumban. A team that started with Kanban and grew to the point where their backlog needed more structure might introduce sprint reviews without abandoning flow-based WIP limits. An organization that scaled to SAFe because of genuine coordination failures might simplify back to a lighter model once teams develop better direct communication habits. The framework is a starting point, not a destination, and treating it as one prevents the kind of learning that makes teams progressively more effective.

Your role as a project manager in an agile environment is not to enforce a framework choice or defend a methodology against criticism. It is to understand why the team made the choices it did, whether those choices are producing the outcomes the organization needs, and what changes would improve the situation. A team running Kanban should be able to explain their cycle time and what it tells them about their workflow. A scaled ART should be able to explain how they surface cross-team dependencies before they become schedule failures. If the team cannot explain those things, the framework is being practiced as ritual rather than as a tool. That gap between ritual and understanding is where project managers add the most value: not by knowing which framework is best, but by asking the right questions about whether the current approach is working and what evidence would tell you if it is not.

Framework fluency matters less than outcome clarity. You can learn the vocabulary of SAFe in an afternoon. Understanding when SAFe solves a real problem and when it adds bureaucratic weight to a team that was fine without it takes judgment that only comes from seeing multiple teams in multiple contexts. Start with the diagnostic questions: what does the incoming work look like? Can it be batched into iterations, or does it arrive continuously? Are multiple teams delivering into the same product? Where are the coordination failures? The answers to those questions point more reliably toward the right approach than any certification course or consultant recommendation. Follow the work. Let the work shape the method, not the other way around.

What's Next

The next chapter covers how agile teams track progress using burndown charts, burnup charts, velocity, and information radiators.

Reflect

• Think of a team or project you have been part of. Would Scrum or Kanban have been a better fit for how work actually arrived and moved through the team? What signals tell you that?
• WIP limits feel counterintuitive to many teams when first introduced. What specific resistance would you expect, and how would you make the case for the constraint?
• SAFe's PI Planning requires all teams in an Agile Release Train to plan together for two days. What organizational conditions would make that investment worthwhile, and what conditions would make it unnecessary overhead?
• If a team told you they are "doing Kanban" but cannot tell you their average cycle time or where their most common bottleneck sits, what does that tell you about how they are using the framework?