Kanban and flow

Not all agile work fits neatly into sprints. Support requests arrive unpredictably, priorities change daily, and some work items take an hour while others take two weeks. For this kind of work, many teams use Kanban, an approach that manages the flow of work rather than organizing it into timeboxes. On Project Compass, the library's IT team uses Kanban for the stream of integration tasks that connect kiosks, security gates, the app and the catalog system: network changes, test accounts, firmware updates, data fixes and vendor tickets.

Where Kanban comes from

Kanban means roughly "signboard" or "visual card" in Japanese. In the Toyota Production System, kanban cards signaled when an upstream process should produce more parts, so that production was pulled by demand instead of pushed by a schedule. In knowledge work, the Kanban method, popularized by David J. Anderson in the late 2000s, applies the same ideas: make the work visible, limit how much is in progress and manage the flow so that work moves smoothly from request to completion. Kanban is described as an evolutionary method: you start with your current process and improve it, rather than replacing it with a new set of roles.

Visualizing the work

A Kanban board shows columns for the stages of the workflow and cards for work items. Unlike a Scrum task board, which is reset each sprint, a Kanban board is continuous: items enter on the left whenever they are requested and leave on the right when they are done. The columns should reflect how work really flows, including waiting states. Making waiting visible is one of the most useful things a board does. The Compass IT team added a "waiting on vendor" column after realizing that items sat for days while kiosk or catalog vendors responded, a delay that had been invisible when everything in progress shared one column.

Boards often use swimlanes to separate classes of work, such as an expedite lane for urgent items, and visual markers for blocked items. Some teams split columns into "doing" and "done" sub-columns so it is clear when an item is waiting to be pulled by the next stage. The goal is that anyone looking at the board can answer quickly: what is being worked on, what is stuck and why.

Limiting work in progress

Work-in-progress (WIP) limits are what turn a board from a picture into a management tool. When a column reaches its limit, nobody starts new work in it; instead, people help finish items already there or remove the blockage that is stopping them. This creates a pull system: work is pulled into a stage when there is capacity, not pushed in because someone upstream has finished their part. Teams new to WIP limits often find them uncomfortable at first because they reveal bottlenecks that were previously hidden by starting more and more work.

Why does limiting WIP help? Multitasking carries a switching cost; every extra item in progress divides attention and delays everything. More importantly, there is a simple mathematical relationship between WIP, throughput and cycle time, known as Little's law. For a stable system, average WIP equals throughput multiplied by average cycle time. Rearranged, average cycle time equals WIP divided by throughput. If the team can finish six items a week, having 18 items in progress means each takes about three weeks on average, whereas having six in progress means about one week.

# Little's law on the kiosk integration Kanban board: average items in progress
# = throughput x average cycle time, so cycle time = WIP / throughput.
throughput_per_week = 6          # items finished per week (stable for a month)
for wip in (6, 9, 12, 18):
    cycle_weeks = wip / throughput_per_week
    print(f"WIP {wip:>2} items -> average cycle time {cycle_weeks:.1f} weeks ({cycle_weeks * 5:.0f} working days)")

WIP  6 items -> average cycle time 1.0 weeks (5 working days)
WIP  9 items -> average cycle time 1.5 weeks (8 working days)
WIP 12 items -> average cycle time 2.0 weeks (10 working days)
WIP 18 items -> average cycle time 3.0 weeks (15 working days)

Starting more work does not make the team finish more; it only makes each item take longer and makes forecasts less reliable. Before WIP limits, the Compass IT team routinely had 15 to 20 items open and requesters complained that nothing ever seemed to finish. After introducing a limit of four in progress, the number of items finished per week stayed about the same, but average cycle time fell from roughly three weeks to just over one, and requesters could get a reliable answer to "when will it be done?"

Measuring flow

Kanban teams use a small set of flow measures. Cycle time is the time an item spends from when work starts on it to when it is done. Lead time usually means the time from when it is requested to when it is delivered, so it includes waiting in the queue before work starts; definitions vary between organizations, so check what a particular question or tool means. Throughput is the number of items finished per unit of time. WIP is the number of items started but not finished. Work item age, the time an item in progress has been open so far, is a useful early warning: an item much older than usual needs attention now, not after it finishes.

A cumulative flow diagram (CFD) shows the number of items in each stage over time as stacked bands. The top edge of the chart shows total arrivals; the bottom band shows items done. The vertical distance between bands at any date is the WIP in those stages; the horizontal distance approximates how long items take to pass through. Bands that widen indicate a growing queue or bottleneck. Bands that run flat mean nothing is moving. Parallel bands that rise steadily indicate healthy, stable flow.

In the Compass CFD, the waiting-on-vendor band swells in weeks 4 to 6 while the kiosk supplier is slow to respond to firmware tickets. The project manager uses the chart in a meeting with the supplier, invoking the response-time clause in the kiosk contract. After week 6 the band narrows. The CFD turned a vague feeling that "the vendor is slow" into a visible, specific issue.

Explicit policies and classes of service

Explicit policies make the rules of the system visible so that everyone handles work the same way. Typical policies include when an item is ready to start, what done means for each column, how items are prioritized and how blocked items are escalated. Classes of service give different kinds of work different treatment. An expedite class handles urgent items that jump the queue, usually limited to one at a time because every expedited item delays the others. A fixed-date class covers items that must be done by a deadline. A standard class is handled first in, first out within priority, and an intangible class covers important but not urgent work such as technical improvements.

Kanban, Scrum and Scrumban

Kanban and Scrum are not rivals. Scrum prescribes roles, timeboxed sprints and specific events; Kanban prescribes none of these and focuses on flow. Many Scrum teams use Kanban practices inside their sprints, such as WIP limits on the task board. Some teams combine them in a hybrid often called Scrumban: they keep regular planning and retrospectives but pull work continuously instead of committing to a fixed batch per sprint. The right choice depends on the nature of the work. Work that benefits from a shared goal and regular stakeholder reviews suits Scrum; interrupt-driven or highly variable work suits Kanban.