Redr · Study Guide
Kanban
Successful Evolutionary Change for Your Technology Business
David J. Anderson
Unofficial AI-assisted study guide. Not affiliated with or endorsed by the author or publisher. For educational use — supplements, not replaces, the original work.
Contents
- 01Solving an Agile Manager's Dilemma
- 02What is the Kanban Method?
- 03A Recipe for Success
- 04From Worst to Best in Five Quarters
- 05A Continuous Improvement Culture
- 06Mapping the Value Stream
- 07Coordination with Kanban Systems
- 08Establishing a Delivery Cadence
- 09Establishing an Input Cadence
- 10Setting Work-in-Progress Limits
- 11Establishing Service Level Agreements
- 12Metrics and Management Reporting
- 13Scaling Kanban
- 14Operations Review
- 15Starting a Kanban Change Initiative
- 16Three Types of Improvement Opportunity
- 17Bottlenecks and Non-Instant Availability
- 18An Economic Model for Lean
- 19Sources of Variability
- 20Issue Management and Escalation Policies
- Part 01 · Introduction01Solving an Agile Manager's Dilemma02What is the Kanban Method?
- Part 02 · Benefits of Kanban03A Recipe for Success04From Worst to Best in Five Quarters05A Continuous Improvement Culture
- Part 03 · Implementing Kanban06Mapping the Value Stream07Coordination with Kanban Systems08Establishing a Delivery Cadence09Establishing an Input Cadence10Setting Work-in-Progress Limits11Establishing Service Level Agreements12Metrics and Management Reporting13Scaling Kanban14Operations Review15Starting a Kanban Change Initiative
- Part 04 · Making Improvements16Three Types of Improvement Opportunity17Bottlenecks and Non-Instant Availability18An Economic Model for Lean19Sources of Variability20Issue Management and Escalation Policies
Part 01
Introduction
Ch. 1–2
Solving an Agile Manager's Dilemma
Anderson recounts his years managing teams at Sprint and Motorola, where he wrestled with how to honor "sustainable pace" while still delivering against aggressive business demand. He concluded that prescriptive process imposition always provokes resistance and that without a guiding model, process adaptation devolves into superstition — seeding his search for an evolutionary, low-resistance approach to change.
The Agile Manager's Dilemma
The manager is squeezed between business demand for more, faster output and the team's need for sustainable pace. Imposing methodologies from above never resolves this tension; only a framework that adapts to context and exposes problems empirically can.
Sustainable Pace
From the Agile Manifesto: a working rhythm a team can sustain indefinitely, roughly a forty-hour week. Anderson treats this as a personal mission — not a perk, but a precondition for predictable knowledge work.
Tailoring Without Superstition
Without a model, every process tweak rests on opinion or folklore. Anderson sought a framework for tailoring that grounds decisions in evidence — visible flow, measurable lead time — so improvements are refutable.
Theory of Constraints Origin
Anderson began applying Goldratt's Five Focusing Steps to software workflows, looking for the bottleneck that limits throughput. This led him to hypothesize that a simplified Drum-Buffer-Rope pull system could regulate flow in knowledge work.
Evolutionary Over Revolutionary Change
Big-bang transformations provoke organizational antibodies. Anderson concluded that change must be incremental and low-resistance — start from current state, change one thing, observe, adapt.
- Sustainable pace
- A work rhythm a team can maintain indefinitely without burnout.
- Theory of Constraints (TOC)
- Goldratt's management theory that throughput is limited by a single bottleneck that must be identified and elevated.
- Drum-Buffer-Rope (DBR)
- A TOC scheduling pattern where the bottleneck (drum) sets pace, a buffer protects it, and a rope ties new-work release to its cadence.
- Bottleneck
- The constraining step in a workflow that limits total throughput.
- Evolutionary change
- Incremental, low-resistance improvement rooted in current state.
- Feature-Driven Development (FDD)
- Anderson's earlier agile method that informed his thinking on workflow stages.
Multiple choice
According to Anderson, what is the core tension that defines the "Agile manager's dilemma"?
Multiple choice
Which TOC artifact did Anderson begin adapting from Goldratt to regulate flow in knowledge work?
True / False
Anderson concluded that big-bang, prescriptive process rollouts are the fastest way to get an organization to adopt a new methodology.
Spot the issue
A new engineering manager inherits a struggling team and immediately announces a switch to a textbook Scrum implementation: two-week sprints, mandatory story-point estimation, fixed roles, and a rewritten definition of done. Within a month, senior engineers are quietly working around the ceremonies, and the manager is convinced the team is just resisting "real Agile." What's the deeper problem with this approach?
What is the Kanban Method?
Anderson defines kanban (Japanese for "signal card") and traces it from Toyota's just-in-time production system to its adaptation for knowledge work. Kanban for software is not a development lifecycle — it is a change-management approach that overlays existing processes, visualizes flow, limits WIP, and uses the resulting tension to expose problems for improvement.
Kanban as Signal
A kanban is a token that authorizes one unit of work — physical in Toyota's factories, virtual on a software team's board. The token is what makes a pull system operationally possible.
Pull System
Downstream demand triggers upstream work. Nothing starts until capacity signals, which prevents overproduction and the runaway queues that plague push-based scheduling.
Visualize the Workflow
A board with columns for each workflow stage and cards for each work item makes intangible knowledge work visible. You cannot improve flow you cannot see.
Limit Work-in-Progress
Explicit caps on the number of items in each stage force the system into a pull discipline and intentionally create tension that surfaces bottlenecks, quality problems, and dependency pain.
Kanban Is Not a Process
Kanban is overlaid on whatever process already exists — "start with what you do now." It does not prescribe roles, ceremonies, or engineering practices.
Toyota Lineage
Kanban inherits from Taiichi Ohno's Toyota Production System: just-in-time delivery, elimination of muda (waste), and respect for the people doing the work.
- Kanban
- Japanese for "signal card"; a token authorizing one unit of work.
- Kanban system
- The full pull-based system created by limiting WIP and circulating kanban signals.
- WIP (Work-in-Progress)
- The count of items started but not yet finished in a workflow.
- Pull system
- Work pulled in only when downstream capacity becomes available.
- Just-in-Time (JIT)
- Produce or start work only when needed, at the rate it is needed.
- Muda
- Japanese for waste; non-value-adding work that Lean targets for elimination.
- Kanban Method
- Anderson's adaptation of kanban for knowledge work as a change-management approach.
Multiple choice
In Anderson's framing, what is a "kanban" in its most literal sense?
True / False
The Kanban Method is a software development lifecycle that prescribes specific roles, ceremonies, and engineering practices.
Multiple choice
What is the operational difference between a push system and a pull system, as Kanban defines them?
Spot the issue
A team adopts a board with columns for analysis, dev, test, and done, and starts moving sticky notes across it. After three months, lead times haven't improved and the same bottlenecks keep recurring. The team has not set any caps on how many cards can sit in each column at once. Per Anderson, what's missing that turns visualization into an actual Kanban system?
Part 02
Benefits of Kanban
Ch. 3–5
A Recipe for Success
Anderson offers a six-step recipe for a manager who has just taken over a team and wants visible improvement with minimal organizational resistance. The sequence — quality first, then WIP reduction, frequent delivery, demand/throughput balance, prioritization, and variability reduction — is designed to build trust before introducing larger changes.
Focus on Quality
Defects waste capacity and erode credibility. Reducing escaped bugs is the highest-leverage starting move because it earns trust from both team and stakeholders.
Reduce Work-in-Progress
Smaller batches mean shorter lead times, less multitasking, and faster feedback. WIP reduction is the gateway to a pull system and to all subsequent improvements.
Deliver Often
Frequent delivery builds business trust and reduces transaction-cost risk. From Reinertsen's small-batch economics: the larger the release, the more painful and rare it becomes.
Balance Demand Against Throughput
Only accept new work into the system at the rate it can be completed. This prevents queue growth and is a precursor to meaningful prioritization.
Prioritize
Once the system is balanced, focus on sequencing the right work to maximize value — a TOC-flavored discipline of doing what matters next, not everything at once.
Attack Sources of Variability
Reduce variability in arrival rate, item size, and processing time to improve predictability. This is the most advanced step — it requires that the prior five are stable.
- Lead time
- Elapsed time from a work item being committed to its delivery to the customer.
- Cycle time
- Elapsed time from when work actually begins to when it is completed.
- Throughput
- Rate of completed work items per unit time.
- Variability
- Statistical variation in arrival, item size, or processing time — the enemy of predictability.
- Batch size
- Number of items processed together; smaller is generally better for flow.
- Cost of Delay
- Economic penalty of not delivering a work item now versus later.
- Predictability
- The ability to reliably forecast when work will be done.
Multiple choice
Which step does Anderson recommend a manager tackle first in his six-step recipe for a new team?
Multiple choice
Why does Anderson place "attack sources of variability" as the last step in the recipe?
Spot the issue
A manager taking over a team decides to immediately reprioritize the entire backlog and reorder every item by business value, before doing anything else. Six weeks later, defect escapes are still high, WIP is unbounded, and stakeholders complain that "the priorities keep changing but nothing ships." Per Anderson's recipe, what did this manager skip?
Spot the issue
A product team ships a major release every nine months. Each release is a multi-week effort involving testing freezes, manual deployment runbooks, and extensive change-approval paperwork. Leadership argues that releasing more often would just multiply this overhead. Per Anderson (drawing on Reinertsen), what is the flaw in this reasoning?
From Worst to Best in Five Quarters
The foundational case study: at Microsoft's XIT Sustained Engineering team in 2004, Anderson and Dragos Dumitriu implemented a Drum-Buffer-Rope pull system with no estimates and strict WIP limits. Within nine months, productivity rose 155%, lead time fell from 5.5 months to 14 days, on-time delivery climbed from near 0% to over 90% — with no new headcount and no changes to engineering practices.
The Original Problem
80+ applications, 3 developers and 3 testers, 5.5-month average lead time, individual items taking up to a year, on-time delivery near zero, and the backlog being re-planned 4-5 times per month.
The Two Key Interventions
Dumitriu proposed two changes: stop estimating individual items and limit WIP, pulling new work only when items completed. Removing estimation freed enormous management capacity and forced item sizes toward a uniform small scale.
Drum-Buffer-Rope at Work
Test was the bottleneck. Test capacity became the drum; a 5-item buffer between development and test protected it; the rope tied new-work release to test completion. WIP limits: one item per developer, one per tester.
The Results
155% productivity gain, lead time 5.5 months → 14 days, throughput 17 → 56 requests per quarter, backlog 80 → under 10, cost per item from $7,500 to $2,900, on-time 0% → 98%. No new resources, no engineering changes.
Realization and Rebranding
Anderson later recognized the DBR implementation was operationally equivalent to a kanban system — same mechanics, different vocabulary. This prompted the rebranding to "Kanban" after the 2007 Corbis presentation.
- XIT
- The Microsoft IT business unit whose Sustained Engineering team Anderson turned around.
- Sustained Engineering
- Software maintenance work — small change requests and bug fixes on existing applications.
- Input buffer
- A prioritized backlog of approved items awaiting pull into the work system.
- Drum
- The bottleneck step that sets the pace of the entire system.
- Rope
- The signaling mechanism tying new-work release to bottleneck completion.
- Due-date performance
- Percentage of items delivered by their committed date.
- Productivity
- Output (completed items or value) per unit of input.
Multiple choice
At the start of the XIT Sustained Engineering turnaround, roughly what was the team's average lead time?
Multiple choice
Which two interventions did Dragos Dumitriu propose to turn the team around?
True / False
The XIT productivity gain was achieved by hiring additional developers and overhauling engineering practices.
Spot the issue
A new manager hears about the XIT case study and decides to copy it. She imposes WIP limits on every column but then tells her senior developers to focus on speeding through coding because "coding is the slow part." Within weeks, a queue of finished code builds up in front of testing and lead times haven't moved. What's the misapplication of the XIT lesson?
A Continuous Improvement Culture
Anderson argues that Kanban's deepest payoff is cultural: the WIP-limited pull system intentionally creates tension that exposes process problems, and an organization that responds to that tension develops a kaizen culture. This culture cannot be mandated — it emerges when leadership at every level is paired with deliberate slack capacity for reflection.
Kaizen as Emergent
Continuous improvement is not a separate practice the organization installs — it is a cultural outcome of running a Kanban system honestly. The board surfaces the problems; the people propose the fixes.
Tension Surfaces Problems
WIP limits make blocking issues, queues, and bottlenecks immediately visible, creating pressure to fix them. Without the limits, problems hide inside large queues and never become urgent enough to address.
Slack Enables Improvement
A system at 100% utilization has no capacity to improve. Deliberate slack must be preserved to allow learning, refactoring, and process change — paradoxically, less work in flight means more work delivered.
Leadership at Every Level
Improvement happens when team members, not just managers, are empowered to identify problems and propose changes. The shared, visible model is what enables anyone to participate meaningfully.
Counter-Intuitive Effects
Limiting WIP feels like doing less but accelerates throughput. This is one reason Kanban's benefits aren't immediately obvious to managers trained to maximize utilization.
- Kaizen
- Japanese for continuous improvement — small, ongoing changes driven by the people doing the work.
- Slack
- Uncommitted capacity within the system that enables learning, improvement, and absorbing variability.
- Little's Law
- L = λW (average WIP equals average arrival rate times average lead time); the formal basis for why reducing WIP shortens lead time.
- Flow
- The smooth, steady movement of work items through the system.
- Explicit policies
- Written, agreed rules about how work is selected, processed, and completed.
- Respect for people
- A Toyota/Lean principle that pairs with kaizen — improvement must not come at the workers' expense.
Multiple choice
In Anderson's view, a kaizen culture is best described as:
Multiple choice
Why does Anderson argue that a system running at 100% utilization cannot improve itself?
True / False
WIP limits hide problems by keeping the board orderly, which is one reason they reduce stress on the team.
Spot the issue
A director reviewing a team's kanban board sees that the "Dev" column is well under its WIP limit, with two slots empty. He immediately tells the team to pull more cards in to "use the capacity we're paying for," reasoning that empty slots are wasted money. Per Anderson, what's wrong with this intervention?
Part 03
Implementing Kanban
Ch. 6–15
Mapping the Value Stream
Designing a kanban system means mapping the team's **actual** workflow, not an idealized one. Anderson walks through setting scope boundaries, identifying work item types and demand patterns, and visualizing flow on a card wall so the team can see, prioritize, and pull work transparently.
Start With What You Do Now
Document existing practices without imposing standards. Preserve team dignity and identity by initially changing only WIP quantities and upstream/downstream interfaces — not roles or engineering methods.
Set Process Boundaries
Define what's inside the system (e.g., analysis, design, coding, testing) and what's excluded (requirements gathering upstream, production deployment downstream). The boundary determines what the WIP limits actually limit.
Identify Work Item Types
Categorize demand: production defects, features, change requests, refactoring, intangibles. Each type may need distinct policies and capacity allocation later.
Card Wall Visualization
Activities arrayed left-to-right; parallel/unordered columns allowed where sequence doesn't matter; buffer and queue columns inserted between activity stages. The wall is the system's user interface.
Ticket Design as Trust Signal
The card captures what the team needs to know — type, due date, blockers, owner. Anderson argues "a well-designed work item card is a key enabler of a high-trust culture."
- Value stream
- End-to-end sequence of activities that transform a customer request into delivered value.
- Card wall / kanban board
- Physical or electronic visualization of the workflow with columns representing process states.
- Work item type
- A category of work (feature, bug, change request) with its own characteristics and policies.
- Ticket
- The token representing one unit of work moving across the board.
- Buffer column
- A queue column that decouples adjacent activities and smooths flow.
- Demand analysis
- Categorizing and counting incoming requests by type to inform capacity allocation.
Multiple choice
When designing a new kanban system, Anderson advises which approach to mapping the workflow?
Multiple choice
What is the purpose of defining process boundaries when setting up a kanban system?
Spot the issue
A team builds their first kanban board with a single column called "Work" containing every active card, regardless of whether items are in analysis, coding, testing, or waiting on a third party. They argue this keeps the board simple. After a month, they cannot tell where work is stuck and lead times keep growing. What's the core mistake?
Multiple choice
Why does Anderson treat work-item ticket design as a "trust signal"?
Coordination with Kanban Systems
With the board in place, the team needs lightweight coordination mechanisms to keep work flowing and surface problems. Anderson describes a small set of meetings and visual conventions that together replace the heavier ceremony of timeboxed processes.
Visual Control as Coordination
The board itself signals when capacity is available; downstream pulls when ready, rather than upstream pushing. Much of the coordination that meetings normally provide is delegated to the board.
Daily Standup
A short board walk-through, typically right-to-left, focused on blockers and flow — not per-person status reports. The card wall, not the people, drives the agenda.
The "After Meeting"
An informal follow-on discussion immediately after standup, attended only by those affected by issues raised. Resolves problems without burdening the whole group.
Queue Replenishment Meeting
A periodic meeting (often weekly) to refill the input queue with prioritized items from stakeholders. This is where commitment happens.
Visual Conventions
Sticky-note colors, avatars, magnets, and badges signal class of service, blockages, and ownership at a glance — turning the board into a dense information radiator.
- Standup
- Brief recurring meeting in front of the board.
- After meeting
- Voluntary follow-up among those affected by an issue raised at standup.
- Blocker
- An impediment that prevents a card from progressing; usually visually flagged.
- Avatar
- A marker on a card identifying who's working on it.
- Replenishment meeting
- Meeting where new work is selected and committed into the input queue.
- Triage
- Sorting and re-prioritizing items based on urgency and value.
Multiple choice
Anderson describes the daily standup in Kanban as primarily a:
Multiple choice
What problem is the "after meeting" specifically designed to solve?
True / False
With a kanban board in place, the board itself does much of the coordination work that meetings normally provide.
Spot the issue
A team holds a 45-minute daily standup where each of eight engineers spends 5 minutes describing every task they touched yesterday, then sits down. Blockers occasionally come up but are deferred to "later." After several weeks the team complains standup is a waste of time and skips it. What's the underlying problem?
Establishing a Delivery Cadence
Delivery cadence is the regular rhythm at which finished work reaches the customer. Anderson argues frequent delivery is desirable, but its feasibility depends on driving down the transaction and coordination costs of a release — making cadence a deliberate economic choice, not a default.
Cadence Decoupled From Scope
Releases happen on schedule with whatever is "done"; scope is not the contract, cadence is. Customers come to rely on the rhythm, not on per-release feature promises.
Transaction Cost of Release
Every release has fixed costs: testing, deployment, paperwork, change-approval. High transaction costs push toward less frequent releases — and reducing them is what enables shorter cadences.
Trust Through Predictability
Customers learn the rhythm; the social cost of "missing" a release diminishes because something else is always shipping soon. Trust accumulates faster than feature velocity.
Reducing Release Overhead
Investments in automation, deployment pipelines, and policies lower per-release cost economically — turning frequent delivery from aspiration to default.
On-Demand Release
Mature systems can release any time a card reaches "done," eliminating cadence entirely — continuous delivery as the limit case of cadence reduction.
- Cadence
- A regular rhythm or heartbeat of an activity.
- Delivery cadence
- The release rhythm to the customer.
- Transaction cost
- Fixed cost of executing a release event.
- Coordination cost
- Cost of aligning people and systems for an event.
- Release
- The act of shipping completed work to its consumer.
- Continuous delivery
- Release on completion rather than on schedule.
Multiple choice
Under Anderson's "cadence decoupled from scope" principle, what is the contract a team makes with its customers about releases?
Multiple choice
According to Anderson, what most directly determines whether a team can shorten its delivery cadence?
Spot the issue
A product manager insists the team must release more frequently to satisfy customers, but every release still requires three days of manual regression testing, a Friday change-control board meeting, and hand-written deployment runbooks. The team pushes back that monthly is already the most they can manage. What's the right intervention?
True / False
On-demand release — shipping the moment a card reaches "done" — is what continuous delivery looks like as the limit case of cadence reduction.
Establishing an Input Cadence
Input cadence is the rhythm at which new work crosses the commitment point into the system. The replenishment meeting is the key ceremony; a faster cadence improves responsiveness and reduces the cost to customers of getting prioritization wrong.
The Commitment Point
The point at which an item becomes a committed work item the team will deliver — distinct from being merely a candidate in the backlog. Commitment is a promise; backlog membership is not.
Replenishment Meeting
The recurring ceremony where stakeholders choose which items enter the input queue next. Anderson's canonical version emerged from bi-weekly teleconferences resolving multi-manager priority conflicts.
Frequency vs Transaction Cost
More frequent input cadences require lower coordination cost. Weekly replenishment is typical; daily is possible if the meeting is cheap.
Late Binding of Priorities
Frequent input cadences let customers defer decisions and respond to new information. Priority commitments age fast in knowledge work, so binding late is valuable.
Avoiding Starvation
A pull system needs the input queue replenished often enough that downstream never sits idle. The cadence must match the rate at which work is consumed.
- Input cadence
- Rhythm of replenishing the input queue.
- Replenishment meeting
- The ceremony where new work is committed into the system.
- Input queue
- The buffer of items committed but not yet started.
- Commitment point
- Where intent becomes a promise to deliver.
- Backlog
- Pool of candidate work items not yet selected.
- Late binding
- Deferring decisions until the last responsible moment.
Multiple choice
What distinguishes a committed work item from one that's merely a candidate in the backlog?
Multiple choice
Why does Anderson value frequent input cadences (weekly or even daily replenishment) over rarer, larger ones?
Multiple choice
What does Anderson identify as the principal trade-off that constrains how frequently a team can run replenishment?
Spot the issue
A team runs replenishment quarterly because the cross-stakeholder meeting is a major event requiring travel and a steering-committee chair. Between meetings the input queue drains and developers sit idle for days at a time, but management resists changing the cadence because "the steering committee owns prioritization." What's the underlying flow problem?
Setting Work-in-Progress Limits
WIP limits are the core mechanic that converts a board into a pull system. Anderson explains heuristics for per-column and per-person limits, the relationship between WIP and lead time via Little's Law, and the political dynamics of agreeing on limits that hold up under stress.
Per-Person Heuristics
1 item per person (preferred minimum, common in maintenance), 1.5 (small buffer for blockers), 2 (each has backup work but quality may suffer). Beyond 2, multitasking dominates and lead time inflates rapidly.
Per-Column Limits
Each activity column gets its own WIP cap to expose where work piles up. A column hitting its limit reveals the downstream constraint.
Team Consensus on Limits
Limits must be agreed by the team; without buy-in they collapse under stress. The number itself matters less than the social contract behind it.
Empirical Adjustment
Start with a reasonable number, observe, adjust. Don't apply formulas dogmatically — the right limit is the one that exposes problems without stalling flow.
Little's Law in Practice
Lead Time = WIP / Throughput. Lowering WIP at constant throughput shortens lead time proportionally; raising WIP without elevating throughput just stretches the queue.
Empty Columns Are Okay
Slack visible on the board signals available capacity, not waste to be filled. Filling every column to its limit is the failure mode WIP discipline prevents.
- WIP limit
- Maximum number of items allowed in a state at once.
- Little's Law
- Lead Time = WIP / Throughput; foundational queueing identity.
- Slack
- Intentional idle capacity that enables flow and improvement.
- Buffer
- A queue placed to absorb variability before a bottleneck.
- Pull
- Work moves only when downstream has capacity.
- Push
- Work is forced forward regardless of downstream capacity — the failure mode WIP limits prevent.
Multiple choice
According to Little's Law applied to a kanban system, what happens to lead time if the team lowers WIP while throughput stays constant?
Multiple choice
Anderson's heuristic for per-person WIP in maintenance work is roughly:
True / False
An empty column on a kanban board is wasted capacity that should be filled with additional work as soon as possible.
Spot the issue
A senior manager dictates that every column on the team's board will have a WIP limit of 5, copying the number from a kanban case study he read. The team is skeptical but accepts the mandate. Within a week, engineers are routinely "borrowing" extra slots when columns fill up, and the limits are widely ignored. What did the manager get wrong?
Establishing Service Level Agreements
Classes of service and SLAs let teams make credible commitments without per-item estimation. Rather than promising individual due dates, teams promise statistical performance — "80% of standard items in 30 days" — per class, and allocate capacity across classes deliberately.
Four Canonical Classes of Service
Expedite, Fixed Delivery Date, Standard, Intangible. Each has distinct policies and a distinct cost-of-delay curve; allocating WIP across them is a strategic decision.
Expedite Class
Drops everything to handle an emergency. Severely limited (often WIP=1) and visually distinct (typically its own swim lane). Used sparingly because every expedite damages mean lead time.
Fixed Delivery Date Class
Has a hard external deadline — regulatory, seasonal, contractual. Scheduled based on the cost-of-delay curve, which is flat until the deadline approaches and then spikes.
Standard Class
The default; most items. FIFO or value-driven ordering within the class. SLA is statistical, not per-item.
Intangible Class
Important but not urgent: refactoring, debt paydown, infrastructure. Reserving capacity for it prevents the tyranny of the urgent from starving long-term health.
Capacity Allocation
Reserve percentages of WIP for each class — e.g., 60% change requests, 30% production fixes, 10% maintenance. The allocation makes priority trade-offs explicit and visible.
- Class of service (CoS)
- A set of policies governing how a type of work is treated.
- SLA (Service Level Agreement)
- Statistical commitment on lead time and due-date performance.
- Cost of delay
- Economic impact of late delivery per unit time.
- Expedite
- Highest urgency class; preempts other work.
- Fixed delivery date
- Class with a hard deadline.
- Intangible class
- Class for important non-urgent work.
- Capacity allocation
- Reserving portions of WIP for specific classes.
Multiple choice
Which class of service is characterized by a flat cost-of-delay curve that spikes sharply as an external deadline approaches?
Multiple choice
A team is being pressured to commit to a per-item due date for every standard feature request. According to Anderson, what is the credible alternative?
Spot the issue
A team has marked nearly a third of incoming work as "Expedite" this month so high-priority customer requests jump the queue. Their mean lead time has gotten worse for everyone, even though each expedite item ships quickly. What's wrong?
Multiple choice
What is the purpose of reserving a percentage of WIP for the Intangible class?
Metrics and Management Reporting
Anderson defines the data-driven feedback that lets managers steer a Kanban system. The headline tool is the cumulative flow diagram, supplemented by lead-time distributions, throughput, due-date performance, and blocker statistics — all surfaced to managers as evidence rather than estimates.
Cumulative Flow Diagram
A stacked-area chart of cards in each state over time. Vertical distance is WIP; horizontal distance is lead time; slope is throughput; widening gaps between bands signal a bottleneck forming.
Lead Time Distribution
A histogram, not an average. The shape of the distribution — tight, fat-tailed, bimodal — drives SLA commitments and exposes variability that a mean would hide.
Due-Date Performance
Percentage of items meeting their promised date, reported per class of service. The honest metric for stakeholder trust; far more meaningful than throughput alone.
Quality Metrics
Initial quality (defect escape rate at delivery) and failure demand (Seddon's term for demand caused by past failures). Both convert intangible quality into countable signals.
Blocker Statistics
Frequency, duration, and source of blocked items — direct input to improvement work. Repeated blockers in one source mean a systemic problem to root-cause.
Reporting Up
Convert flow data into the financial and risk language executives respond to: cost-of-delay impact, throughput in dollars, predictability as risk reduction.
- Cumulative Flow Diagram (CFD)
- Time-series stacked chart of items per state.
- Lead time distribution
- Histogram showing the spread of lead times.
- Throughput
- Items completed per unit time.
- Due-date performance
- Percent of items meeting promised delivery date.
- Failure demand
- Demand caused by failure to do something right earlier.
- Initial quality
- Defect escape rate at delivery.
Multiple choice
On a Cumulative Flow Diagram, what does a widening gap between two adjacent bands typically indicate?
Multiple choice
Why does Anderson insist on reporting lead time as a distribution rather than a single average?
Spot the issue
A manager proudly reports to executives that the team's throughput rose 20% this quarter, and recommends no further changes. Stakeholders, however, complain that they can never trust when their items will ship. What's missing from the manager's reporting?
True / False
According to Anderson, repeated blockers from the same source should be tolerated as long as each individual blocker is cleared within a day.
Multiple choice
When reporting Kanban data upward, what language does Anderson recommend translating flow metrics into?
Scaling Kanban
Anderson extends Kanban beyond a single team via swim lanes, multiple linked kanban systems, and a two-tier approach where a higher-level board tracks programs while team-level boards track tasks. The philosophy is "scaling by not scaling" — link many small service-oriented kanbans rather than build one enterprise system.
Horizontal Swim Lanes
Rows on the board separating classes of service, work types, or parallel projects. Lane count can itself be a WIP allocation mechanism.
Two-Tier Kanban Systems
A higher-level board tracks larger items (features, MMFs, projects); a lower-level board tracks the team tasks that decompose them. Cadences flow between the tiers.
Linked Kanban Systems
Multiple boards connected by upstream/downstream interfaces, each with its own WIP limits and cadences. Each models a service with its own SLA.
Scaling by Not Scaling
Compose many small kanbans rather than enlarge one. Each system is independently optimizable; integration happens at clearly defined interfaces, not by merging boards.
Shared Resources
Specialists like DBAs or UX designers used across systems are modeled explicitly; their capacity becomes a visible constraint rather than an invisible one.
- Swim lane
- A horizontal row on a kanban board dedicated to one class, type, or stream.
- Two-tier system
- A program-level board above a team-level board.
- MMF (Minimum Marketable Feature)
- A small unit of customer-visible value (Denne & Cleland-Huang).
- Shared resource
- A specialist used across multiple kanban systems.
- Scaling by not scaling
- Composing many small kanbans instead of building one big one.
- Service-oriented kanban
- Each board models one service with its own SLA.
Multiple choice
Anderson's philosophy of "scaling by not scaling" prescribes which approach?
Multiple choice
In a two-tier kanban system, what tracks on the higher-level board versus the lower-level one?
Spot the issue
A scaling team has a shared DBA who handles schema changes for five product squads. None of the boards show the DBA's queue; each squad's board just has a "waiting on DBA" sticker. Squads keep getting blocked unpredictably. What's the structural fix?
Multiple choice
What can horizontal swim lanes be used for, beyond separating classes of service?
Operations Review
The operations review is the cross-organization feedback meeting — a monthly forum where managers from across the organization present flow metrics and identify improvements that cross team boundaries. Anderson positions it as the keystone cadence that institutionalizes kaizen at the management tier.
Monthly Cadence
Frequent enough for real intervention but slow enough for trends to appear in the metrics. Quarterly is too slow; weekly is too tactical.
Quantitative Emphasis
Presented with CFDs, lead-time distributions, throughput, due-date performance, value-added efficiency. Data, not opinion, drives the discussion — which removes blame and depoliticizes the room.
Cross-Functional Attendance
Managers from divisions, departments, and supporting systems attend. Each functional manager presents ~8 minutes; team leads ~5 minutes. Engineers invited as observers learn to "think like managers."
System, Not Team
The discussion is about flow between teams and shared resources — hand-off inefficiencies, queue depths between boards — not individual or team performance.
Anchor of Kaizen Culture
By making improvement a monthly, evidence-based ritual, the operations review embeds continuous improvement as an organizational habit, not a one-time initiative.
- Operations Review
- Periodic cross-system management feedback meeting.
- Hand-off inefficiency
- Waste created at boundaries between teams or systems.
- Value-added efficiency
- Ratio of touch time to total elapsed lead time.
- Systemic issue
- A problem caused by interactions between teams, not within one team.
- Evidence-based management
- Decision-making rooted in flow data rather than opinion.
- Cross-functional review
- Forum with managers from multiple disciplines.
Multiple choice
Why does Anderson favor a monthly cadence for the Operations Review over quarterly or weekly?
Spot the issue
At a recent Operations Review, the discussion devolved into blame: "Team A misses deadlines because Person X is slow." The meeting ended without identifying systemic fixes. According to Anderson, what principle was violated?
Multiple choice
How does Anderson argue the Operations Review depoliticizes cross-organizational discussion?
Multiple choice
Why does Anderson recommend inviting engineers as observers to the Operations Review?
Starting a Kanban Change Initiative
Anderson pulls the prior mechanics together into a recipe for rolling out Kanban inside an organization. The defining stance is evolutionary: start with the existing process, agree to pursue improvement, respect current roles — so adoption is low-risk and culturally tolerated.
Start With What You Do Now
Don't redesign the process up front. Map the actual workflow first; only after the system is visible should you propose changes to it.
Agree to Pursue Evolutionary Change
Get explicit buy-in to incremental improvement, not a big-bang transformation. This is the social contract Kanban runs on.
Respect Current Roles and Responsibilities
Don't threaten identities. People engage with change when their job titles and core responsibilities aren't in immediate jeopardy.
Build the System Stepwise
Map value stream → set boundaries → design tickets → agree WIP limits → set cadences → add classes of service. Each step builds on the prior; skipping ahead causes resistance.
Anchor Improvement in Metrics
Make every proposed change refutable against CFDs, lead times, and throughput. The data, not the proposer's seniority, decides what stays.
- Evolutionary change
- Incremental, low-resistance organizational change rooted in current state.
- Change initiative
- A deliberate program of organizational improvement.
- Resistance to change
- Predictable pushback when norms shift; managed via gradualism.
- Buy-in
- Explicit agreement from stakeholders to proceed.
- Roll-out
- The phased introduction of Kanban practices.
- Stakeholder engagement
- Active involvement of customers and managers in cadences and reviews.
Multiple choice
A new manager arrives at a struggling team and immediately announces a redesigned workflow with new roles and ceremonies before mapping the existing process. According to Anderson, what's the most likely outcome?
Multiple choice
Why does Anderson insist that a Kanban roll-out respect current roles and responsibilities?
Spot the issue
A team installs WIP limits and classes of service in their first week, before mapping the value stream or setting process boundaries. Within a month, adoption stalls and the team reverts to ad-hoc work. What stepwise principle did they violate?
Multiple choice
What does Anderson mean by anchoring improvement in metrics?
Part 04
Making Improvements
Ch. 16–20
Three Types of Improvement Opportunity
Anderson opens Part 4 by framing improvement work around three lenses: bottlenecks (Theory of Constraints), waste and economic costs (Lean), and variability (Deming). Each lens directs attention to different signals on the kanban board, and managers must learn to pick the right lens for the symptom.
Theory of Constraints Lens
Focus on the bottleneck and its five focusing steps. Signals on the board: full input queues, idle downstream stations, WIP piling up at one column.
Lean Waste Lens
Focus on muda (waste), mura (unevenness), and muri (overburden), and on transaction and coordination costs. Signals: handoff queues, rework loops, coordination-heavy ceremonies.
Deming Variation Lens
Focus on common-cause vs special-cause variation. Signals: wide lead-time histograms, frequent expedites, blockers from unpredictable external dependencies.
Multiple-Model Thinking
No single model explains every problem. Managers must hold all three lenses and choose deliberately — applying TOC to a variability problem (or vice versa) misallocates attention.
Queues Are Diagnostic
Every queue on the board is an improvement opportunity mapping to one of the three lenses. Reading queues correctly is the core diagnostic skill.
- Muda
- Japanese for waste; non-value-adding work.
- Mura
- Unevenness or irregularity in flow.
- Muri
- Overburden of people or equipment.
- Theory of Profound Knowledge
- Deming's system — appreciation for a system, theory of variation, theory of knowledge, psychology.
- Common-cause variation
- Random variation inherent in a stable process.
- Special-cause variation
- Variation from identifiable, assignable causes.
Multiple choice
Which three lenses does Anderson recommend that managers hold simultaneously when looking for improvement opportunities on a kanban board?
Multiple choice
A column on the board is consistently full while the column downstream of it sits idle. Which improvement lens is most directly suggested by this signal?
Spot the issue
A manager notices her team's lead-time histogram is wide and bimodal, with frequent expedite-driven spikes. She decides the fix is to hire one more developer to "elevate capacity" and ignores the histogram shape entirely. What's wrong with her diagnosis?
Multiple choice
In Anderson's framing, what makes every queue on a kanban board valuable to a manager?
Bottlenecks and Non-Instant Availability
Anderson applies TOC's Five Focusing Steps to knowledge work and distinguishes **true** capacity-constrained resources from **non-instant availability** — people or assets that look constrained but are actually just shared or multitasked. Elevation by hiring is usually counterproductive in the short term.
Five Focusing Steps
Identify, Exploit, Subordinate, Elevate, repeat (and beware inertia). The order matters: don't elevate before you've exploited and subordinated.
Exploit the Bottleneck
Protect it with a buffer, prevent it from idling, ensure only high-quality work reaches it. Every minute the bottleneck idles is a minute of system throughput lost forever.
Subordinate Everything Else
Non-bottleneck resources slow to match bottleneck pace. Running them faster only inflates inventory ahead of the constraint — looks productive, isn't.
Elevate as Last Resort
Adding capacity has high coordination and onboarding cost and slows delivery short-term. Only elevate after exploit and subordinate have stopped paying.
Non-Instant Availability
A shared specialist (DBA, security reviewer) isn't truly capacity-constrained — they're available but not on-demand. Address with automation, policy, or dedicated allocation, not headcount.
Automation as Elevation
Automating tedious specialist work elevates capacity without adding people. Often the cheapest and fastest form of elevation in knowledge work.
- Capacity-Constrained Resource (CCR)
- Formal TOC term for the binding constraint.
- Non-Instant Availability (NIA)
- Resource available but not on demand; behaves like a constraint without being one.
- Exploit / Subordinate / Elevate
- The three action verbs of TOC after identifying a constraint.
- Drum-Buffer-Rope
- TOC scheduling pattern — drum (bottleneck), buffer (protection), rope (release control).
- Idle time
- Unused capacity; acceptable at non-bottlenecks, catastrophic at the bottleneck.
- Inertia
- Failing to re-identify the constraint after it has moved.
Multiple choice
In what order does Anderson say the Five Focusing Steps must be applied to a constraint, before considering inertia?
Spot the issue
A team's testing column is the bottleneck. The dev lead, eager to look productive, pushes developers to keep coding at full speed so that the input buffer ahead of test stays packed with ready work. WIP ahead of test balloons, but throughput doesn't improve. What TOC principle has been violated?
Multiple choice
A shared DBA is available across multiple teams but only on request, causing recurring waits. Anderson would classify this as which kind of problem, and recommend which class of remedy?
Multiple choice
Why does Anderson describe automation as a particularly attractive form of elevation in knowledge work?
An Economic Model for Lean
Anderson reframes Lean's "waste" in economic terms because the manufacturing categories don't translate cleanly to knowledge work. He proposes that value-added work is offset by three cost categories — transaction costs, coordination costs, and failure load — giving managers a more actionable framework.
Value-Added vs Cost Activities
Separate work the customer would pay more for from overhead. The test: "would we do more of this if we could?" If no, it's a cost.
Transaction Costs
Setup and teardown overhead per batch of work: release ceremony, environment setup, change-control paperwork. Reducing these enables smaller batches.
Coordination Costs
Interpersonal scheduling and communication overhead: meetings, handoffs, approvals. Kanban reduces these by turning the board into a passive communication medium.
Failure Load
Demand created by past quality failures — rework tickets, defect escalations, support calls. Failure load consumes capacity that could be doing value-added work; it's the opportunity cost of poor quality.
Economic, Not Ideological
Lean reframed as reduce non-value-added costs without reducing throughput. The framing makes trade-offs explicit and avoids the religious-war tendencies of "waste" discourse.
- Transaction cost
- Overhead per batch of work (release ceremony, environment setup).
- Coordination cost
- Overhead from scheduling and communication among people doing the work.
- Failure load
- Demand caused by past quality failures (rework, defect tickets, support escalations).
- Value-added activity
- Work directly producing customer-perceived value.
- Throughput accounting
- TOC-derived accounting valuing throughput, inventory, and operating expense.
- Opportunity cost
- Value lost from not doing the next-best alternative with the same capacity.
Multiple choice
What are the three cost categories Anderson uses to reframe Lean "waste" in economic terms for knowledge work?
Multiple choice
A team's deployments require two days of paperwork and environment setup, so they release only quarterly. Which cost category does this directly illustrate, and what does reducing it enable?
True / False
Anderson argues that "failure load" — demand created by past quality failures — should be ignored in capacity planning because it represents work that is already lost.
Spot the issue
A team complains that almost half their cycles go to "rework tickets" and emergency support calls from prior releases, leaving little time for new features. Their manager proposes hiring two more developers. Through Anderson's economic Lean lens, what is the better diagnosis?
Sources of Variability
Anderson catalogs internal and external sources of variability in knowledge work and argues that **predictability matters more than raw throughput** because predictability is what builds trust with stakeholders. He uses Deming and Shewhart's distinction between common-cause and special-cause variation as the analytical frame.
Internal Sources
Work item size, work type mix, class-of-service mix, irregular flow, rework loops. These are inside the team's control — first place to look.
External Sources
Requirements ambiguity, expedite requests, environment availability, shared-service scheduling. Less controllable but addressable through policy, SLAs, and engagement design.
Predictability Over Throughput
A slower-but-predictable system is more valuable to customers than a faster-but-erratic one. Trust is built by hitting commitments, not by maximum speed.
Standardize Item Sizes
Splitting work to roughly equivalent sizes narrows the lead-time distribution. Variability in size is one of the largest controllable variability sources.
Limit Expedites
Every expedite damages mean lead time for everyone and spreads variability through the system. Treat expedite as a precious resource, not a default response to pressure.
Quality as Variability Reducer
Defects create rework loops that dominate variation. Investing in initial quality is the highest-leverage variability reduction available.
- Common-cause variation
- Random, inherent fluctuation in a stable process.
- Special-cause variation
- Non-random variation from an identifiable event.
- Statistical Process Control (SPC)
- Shewhart's method for distinguishing the two via control charts.
- Expedite
- A class of service that jumps the queue with no WIP limit, used sparingly.
- Lead-time distribution
- Histogram of actual cycle times; its shape exposes variability.
- Rework loop
- Backward flow caused by defects or rejections.
Multiple choice
Anderson argues that customers value which property of a delivery system above raw speed?
Multiple choice
Which of the following is the LEAST controllable, "external" source of variability Anderson catalogs?
Spot the issue
A product owner is proud that any urgent stakeholder request is processed as an expedite, and 30% of items now travel through the expedite swim lane. The team's lead-time distribution has grown wide and unpredictable, and standard items frequently miss their SLA. What variability principle is being violated?
Multiple choice
Anderson singles out which intervention as the highest-leverage way to reduce variability in a knowledge-work system?
Issue Management and Escalation Policies
Anderson closes with practical mechanisms for surfacing, tracking, and resolving blocked work. Issues are signaled visually, discussed daily at standup, escalated via explicit written policy — and the manager's primary job is to clear them quickly.
Visual Blockers
Mark blocked items prominently — pink stickies, red borders, magnets. The blocker must be impossible to ignore; quiet blockers stay stuck.
Blocker Clustering
Patterns of repeated blockers indicate systemic issues to fix at root cause. Tracking blocker source and duration over time exposes the deeper problem.
Daily Standup as Triage
Focus the standup on blocked items first, not status reporting. The meeting's job is to surface impediments and assign them, not to summarize who did what.
Explicit Escalation Policy
Written rules for who to call, when, and after how long. Without explicit policy, blockers languish because no one knows when to escalate.
Manager's Job Is Clearing Blockers
Managers are measured on resolution speed, not on directing the work. Mean Time to Resolution for blockers is the manager's flow metric.
Root-Cause Prevention
Beyond resolving today's blocker, change policy or process so it cannot recur. A blocker fixed at root saves the resolution cost on every future occurrence.
- Blocker / Blocked work item
- Work that cannot progress due to an external dependency.
- Escalation policy
- Predefined path for raising unresolved issues up the chain.
- Issue log
- Record of blockers used for trend analysis.
- Ready queue
- Buffer of analyzed, prioritized items ready to be pulled into work.
- Impediment
- Scrum-derived term used synonymously with blocker.
- Mean Time to Resolution (MTTR)
- Average elapsed time to clear blocked items.
Multiple choice
According to Anderson, what is the primary purpose of the daily standup in a Kanban system?
Multiple choice
Anderson argues that a manager in a mature Kanban system should primarily be measured on what?
Spot the issue
A team has a clearly defined "escalate after 24 hours" policy on its board. Despite this, a single blocker — an external security review — has stalled the same kinds of cards three times in the past month. Each instance is resolved quickly, but it keeps happening. Where is the team falling short of Anderson's prescription?
Multiple choice
Why does Anderson insist that blockers be marked visually with pink stickies, red borders, or magnets?
Key Takeaways
Kanban is a change-management method, not a software process — it overlays whatever you already do and surfaces improvement opportunities through visualization and WIP limits.
Limiting work-in-progress converts a board into a pull system; Little's Law guarantees that lower WIP at constant throughput means shorter, more predictable lead times.
Classes of service (expedite, fixed-date, standard, intangible) let teams make statistical SLA commitments without per-item estimation by allocating capacity by economic risk.
Cadences — replenishment, delivery, operations review — decouple commitment, flow, and feedback so each can be optimized independently of the others.
Three lenses drive improvement: Theory of Constraints (bottlenecks), Lean (transaction/coordination/failure-load costs), and Deming's variation (common-cause vs special-cause).
Evolutionary change beats revolution because it respects existing roles and lowers resistance — start with what you do now, then let tension from WIP limits drive kaizen.