Book summary “Kanban”: summary

Introduction

You face relentless pressure to deliver software faster while your team drowns in unreasonable schedules and developer burnout. Traditional prescriptive methodologies demand radical organizational surgery, yet they routinely fail to fix chronic delivery bottlenecks.

David J Anderson presents Kanban as an evolutionary change method that starts with your existing process. Instead of forcing disruptive reorganizations, you use visual pull systems and work-in-progress limits to catalyze continuous improvement without initial resistance.

The book guides you from basic workflow visualization and queue management to advanced metrics, hierarchical requirements, and executive feedback loops.

• How do you design a pull system that matches demand with delivery capacity?
• What steps move you from local optimization to enterprise-wide maturity?

1. What is a Kanban System

A kanban system regulates workflow by circulating a fixed number of signal cards that restrict work-in-progress, preventing team overload and aligning incoming demand with actual delivery throughput.

Core Properties and Pull Mechanics

You can manage workflow through a pull system where new tasks start only when a signal card becomes available. This mechanism naturally limits work-in-progress and ensures that you are not overwhelmed by continuous incoming demands.

• Place a number of cards equivalent to the agreed capacity of a system into circulation.
• Attach one card to one piece of work as a signaling mechanism.
• Start a new piece of work only when a card is available.
• Detach and recycle the card when work is completed so a new piece of work can be started from the queue.

Card walls or digital whiteboards used in agile teams are merely visual control systems and do not qualify as kanban systems unless they enforce explicit work-in-progress limits and pull signals. While card walls allow teams to self-organize and visualize tasks moving from a backlog to completion, they fall short of true kanban systems if work items can be added without restriction. A true system requires explicit work-in-progress constraints and pull signaling.

The Kanban Method operates as a complex adaptive system driven by five foundational properties designed to seed continuous improvement. Rather than prescribing a fixed software development lifecycle, Kanban introduces simple rules and initial conditions that foster emergent Lean behaviors tailored to your specific context.

• Visualize Workflow
• Limit Work-in-Progress
• Measure and Manage Flow
• Make Process Policies Explicit
• Use Models to Recognize Improvement Opportunities

The Imperial Palace Visit

On April 9, 2005, the author visited the East Gardens of the Imperial Palace in Tokyo. You received plastic admission cards upon entry and returned them at the exit kiosk, realizing it functioned as a manual kanban system to control crowd size and protect the park.

These five properties have been consistently present across all successful implementations, including the early rollouts at Microsoft and Corbis.

Kanban acts as a permission giver that liberates teams from rigid software development methodologies and practice-based maturity models, empowering them to evolve a unique process tailored to their context. Traditional agile frameworks and maturity models enforce strict conformity and standardized practices. Kanban challenges this by granting you the autonomy to experiment, deviate from textbooks, and optimize your own unique value streams.

Visitors touring the author's department at Corbis in 2007 were surprised to find different teams operating under completely unique kanban boards and processes.

2. Implementing the Recipe for Success

A technical manager inheriting an existing team should follow a strict six-step sequence that moves from areas under sole managerial control to broader cross-functional collaboration.

The Six-Step Sequence

The six steps are executed in order because earlier steps require little collaboration and build the trust and political capital needed for harder, cross-functional steps later. Quality and WIP limits come first to establish basic performance and predictable delivery before trying to optimize prioritization or tackle behavioral variability.

• Focus on Quality
• Reduce Work-in-Progress
• Deliver Often
• Balance Demand against Throughput
• Prioritize
• Attack Sources of Variability to Improve Predictability

Focusing on Quality and Reducing WIP

Excessive defects represent the largest waste in software development, and longer lead times caused by high work-in-progress severely degrade initial code quality. Data shows that average teams spend a massive portion of their capacity fixing defects. Furthermore, an increase in work-in-progress linearly expands lead times, and this extended lead time results in a disproportionate, non-linear explosion of initial defects due to the degradation of human tacit knowledge over time.

At Motorola, two teams developed similar server applications. One team kept high WIP with ten features per developer and a three-month lead time, resulting in industry-average defects of about two per feature. The other team limited WIP to five to ten features total, achieved a five to ten day lead time, and produced initial quality of two to three defects per 100 features.

Balancing incoming demand against actual throughput and limiting work-in-progress uncovers the value stream bottleneck and generates the slack capacity necessary for continuous improvement. When work-in-progress is limited and new requirements are pulled only as capacity frees up, non-bottleneck workers gain slack time. Instead of trying to eliminate this slack through resource balancing, organizations need it so workers can refine skills, tools, and processes, ultimately changing the organizational culture.

A process should be viewed as a set of explicit policies governing behavior that are entirely under management control and can be adjusted to eliminate wasteful practices. Many operational problems stem from outdated local policies rather than mandated methodology frameworks. By identifying and altering counterproductive internal policies, such as requiring expensive rough estimates or handling sporadic rush tasks, managers can instantly recover lost capacity and reduce process variability.

Dragos Dumitriu managed an XIT maintenance team bound to strict corporate PSP/TSP and CMMI mandates. Instead of changing engineering methods, he stopped doing ROM estimates, which wasted up to 40 percent of capacity, and explicitly limited WIP to one request per developer and tester.

Implementing a basic WIP-limited pull system on a distributed maintenance project dramatically increases throughput and predictability without altering core software engineering practices. By visualizing the workflow, limiting work-in-progress, and leveling resources to match the actual bottleneck, a team can eliminate backlogs entirely, slash lead times, and achieve massive productivity gains with minimal political risk.

Dragos Dumitriu's Microsoft XIT sustaining engineering team in Hyderabad and Redmond eliminated an 80-item backlog entirely by November 2005, increased throughput threefold, reduced lead times by over 90 percent, and won the Microsoft Engineering Excellence Award.

3. Defining Control Boundaries and Cards

Starting with Kanban requires changing as little as possible about current roles, job titles, and workflow to minimize resistance and avoid disrupting professional pride.

Evolutionary Start Points

You should resist the temptation to change workflow, job titles, roles, responsibilities, and specific working practices when you begin. Map the value stream as it actually exists rather than re-documenting an official unused process. The primary target of change should be the quantity of WIP and the interfaces with upstream and downstream parts of the business. You must map the actual process because card walls only function if they reflect reality.

Kanban implementation boundaries should align with the team's immediate span of political control, negotiating interactions without forcing external departments to change.

You should stick to visualizing work and limiting WIP strictly within your own political sphere of influence. You should negotiate new ways of interacting with immediate upstream and downstream partners without forcing those partners to adopt a pull system or change their internal job procedures. Different types of work arrive at different rates and exhibit different variation patterns, ranging from steady arrivals to unpredictable bursts. Understanding these patterns helps you determine how much slack or capacity to allocate in swim lanes.

At Corbis, the Rapid Response Team used scheduled bi-weekly releases and weekly prioritization meetings, utilizing an Engineering Ready input queue with a WIP limit of five items and WIP limits throughout analysis, development, build, and system test. The software engineering department budget was funded for software maintenance with 10 percent additional budget, five additional people added for software maintenance, and the WIP limit set for the Engineering Ready input queue. Release cadence in weeks for maintenance releases was scheduled for 1 p.m. every second Wednesday, with 10 in the morning set for prioritization meetings at 10 a.m. every Monday.

You must follow these practices to handle incoming demand properly:

• Identify the types of work arriving at the starting point of the workflow.
• Study the demand for each work item type using historical data or subjective analysis.
• Allocate capacity within the kanban system according to demand and the risk profile.

Anatomy of a Work Item Card

A well-designed card features an electronic tracking number, a title, the entry date for FIFO queuing and service-level agreement tracking, and required delivery dates for fixed-date items. Visual markers such as stickers, avatars, or name tags indicate who is working on an item and flag late items. These details empower individuals to make autonomous pull and scheduling decisions.

You must format physical cards with specific data points:

• Place the electronic tracking number in the top left of the card.
• Write the item title in the middle of the card.
• Put the entry date in the bottom left to facilitate FIFO queuing and service-level agreement tracking.
• Write the required delivery date in the bottom right for fixed delivery date items.
• Attach stickers, magnets, or avatars to show assigned personnel and highlight items late against target lead times.

4. Coordination and Cadences

Kanban decouples prioritization, development, and delivery cadences from one another, replacing rigid time-boxed iterations with on-demand flow and structured replenishment meetings.

Decoupling Cadences

Traditional Agile time-boxes force planning, estimation, and delivery to happen on the same tight schedule. This pressure leads to artificial story splitting or phase-based iteration workarounds. Kanban allows each activity to operate at its own natural, efficient cadence.

Making software deliveries incurs both physical transaction costs and administrative coordination costs. You can increase your delivery efficiency by reducing these costs or adjusting the time between deliveries.

In an example with a $1.5 million total release cost consisting of a $1.3 million burn rate and $200,000 in out-of-pocket delivery costs, plus $300,000 in coordination and transaction costs, the efficiency percentage is calculated as 66.7 percent.

• Calculate Delivery Efficiency percentage using the formula: 100 percent times (Total Cost minus (Coordination Cost plus Transaction Cost)) divided by Total Cost of Software Release.

Queue Replenishment and Standups

Holding weekly prioritization meetings with senior business owners who have decision-making authority creates healthy collaborative tension. Regular queue replenishment meetings reduce coordination costs and align stakeholder priorities.

At Corbis in September 2006, sustaining engineering served six competing departments. A dedicated project manager and build engineer were assigned to handle minor upgrades and bug fixes via a weekly Monday meeting, backed by 10 percent additional funding authorized for software engineering, translating to 5 headcount.

• Invite business representatives who are as senior in their organizations as possible.
• Include stakeholders responsible for delivery, technical functional managers, technical or data architects, usability professionals, operations specialists, and business analysts.
• Schedule replenishment meetings at regular, frequent intervals such as weekly.
• Review each item on the backlog to decide whether it should remain or be deleted.
• Prune the backlog if it exceeds three months worth of delivery throughput in volatile domains, or up to one year in very low volatility domains.

The Microsoft XIT team deleted any item older than six months at a regular monthly interval, reasoning that unselected items were unlikely to hold significant value.

Because the board already displays who is working on what and what is blocked, you walk the board from right to left in the direction of pull. Kanban daily standup meetings focus on workflow and impediments by walking the board backward rather than going around the room asking traditional status questions.

Daniel Vacanti ran a successful standup with more than 50 people at Corbis in 2007, completing the meeting in around 10 minutes by focusing only on blocked or defective tickets. Up to 12 people usually attend a typical standup, though mature setups can scale to more than 50 people completed in around 10 minutes.

• Hold the meeting in the morning before work starts.
• Walk the board backward from right to left in the direction of pull.
• Focus special emphasis on blocked items, delayed items due to defects, and stuck tickets.
• Discuss who is working on an open issue and when it will be resolved.
• Issue a call for any other blocking issues not yet on the board and ask if anyone needs help.

When team members telecommute or work across multiple international sites, electronic tools alone are insufficient. At Corbis, telecommuters used sticky buddies, peer-to-peer agreements with office-present colleagues, to update physical walls when electronic statuses changed via VPN, and the test team operated from Chennai, India.

• Use an electronic tracking system as a supplement or alternative to card walls.
• Make a specific team member responsible for keeping physical card walls synchronized at each geographic location on a daily basis.
• Ensure local responsible personnel synchronize physical boards with electronic systems prior to telephone or video-conference standups.
• Form peer-to-peer agreements where an office-based delegate updates physical cards for telecommuting colleagues.

5. Limits, Queues, and Classes of Service

WIP limits should be chosen by consensus with stakeholders to ensure commitment and avoid misusing the system under stress.

While limits can be declared unilaterally, gaining consensus from up- and downstream stakeholders and senior management creates a collaborative agreement. When pressure mounts, you can fall back on this agreement to protect the design rather than bending the rules.

• Agree upon WIP limits through consensus with up- and downstream stakeholders and senior management.
• Set WIP limits for work tasks as an average number of items per person, developer pair, or small team, typically in the range of one to three items.
• Adjust all WIP limits empirically as an ongoing process.

Queues absorb variation between workflow steps, and buffers protect bottlenecks from starving. If queue and buffer sizes are too small, lead times become unpredictable due to stop-and-go behavior; if too large, they needlessly increase lead time.

• Keep queue and buffer sizes as small as possible while ensuring optimal bottleneck performance.
• Determine input queue size from the prioritization cadence and the team production rate.
• Empirically adjust queue sizes by reducing or increasing them by one item based on whether they fully deplete before replenishment meetings.

Early adopters who avoided WIP limits due to perceived team chaos struggled, saw limited improvement, and often abandoned Kanban. Imposing a WIP limit creates healthy friction that forces discussions about workflow blockages and accelerates organizational maturity.

At Yahoo!, early teams chose not to set WIP limits assuming their teams were too chaotic, but this proved problematic and several teams abandoned Kanban or were disbanded.

Classes of Service and Cumulative Flow

Work can be categorized into Expedite, Fixed Delivery Date, Standard, and Intangible classes of service to balance urgency and long-term value.

Offering different classes of service provides customer flexibility at an economically optimal cost. Each class carries explicit policies governing how items are pulled, whether they require estimation, and what service-level agreement applies.

• Define up to six classes of service based on business impact and risk.
• Clearly display the class of service visually using different colored cards or separate swim lanes.
• Assign the class of service when the item is selected into the input queue.

Expedite items demand immediate interruption of other work. Fixed Delivery Date items have hard external deadlines with high costs of delay. Standard items represent normal work with target lead times and SLAs. Intangible items have low near-term costs of delay and serve as slack capacity.

At Microsoft in 2005, SQL Server 2005 replaced the 2000 edition, giving customers a ten-year support window until 2010 to upgrade incompatible code without immediate cost of delay early on.

• Conduct comparative demand analysis across different types of work.
• Allocate capacity percentages and set swim-lane WIP limits accordingly.

A kanban wall with a total WIP limit of 20 cards allocates capacity across swim lanes as 60 percent for change requests, 10 percent for maintenance items, and 30 percent for production text changes.

• Track WIP using a cumulative-flow diagram to monitor day-to-day WIP limits.
• Scan the cumulative-flow chart horizontally to read average lead times.

A cumulative-flow diagram displays the quantities of work-in-progress across each workflow stage. Smooth bands and stable heights indicate that WIP limits are being successfully maintained and that the system flows correctly.

• Track lead time for each processed item and report both mean and spectral analysis for each class of service.
• Include Fixed Delivery Date items in the due-date performance metric by comparing estimated versus actual lead times.

Spectral analysis of lead time plots actual delivery times against service-level agreements to reveal statistical outliers and improvement opportunities. Unlike simple averages, spectral analysis highlights items that narrowly missed target dates and identifies root causes.

• Measure flow efficiency as the ratio of lead time to assigned engineering time to identify potential for improvement.
• Report initial quality as the number of bugs discovered by testers relative to total WIP and throughput.
• Track failure load to identify the percentage of work generated through poor system quality.

6. Hierarchical Requirements and Operations Review

Large projects require two-tiered boards to manage coarse-grained requirements, while the monthly Operations Review provides an objective data-driven feedback loop that drives organizational maturity.

Major projects often have requirements up to three levels deep. Treating coarse-grained requirements like Minimal Marketable Releases as single flow items causes massive size variability and unpredictable lead times. A two-tiered approach tracks coarse-grained requirements vertically and small user stories horizontally to enable smooth flow and predictability.

On a major project, each larger requirement tracked with green tickets broke out into an average of 21 smaller features tracked with yellow tickets.

• Agree on prioritization cadence for input queue replenishment.
• Agree on integration or synchronization cadence.
• Define work item types for different levels of the hierarchy.
• Track the two top levels of requirements on the kanban board.
• Set WIP limits at both levels of the hierarchy.

The Monthly Operations Review

The monthly Operations Review is the keystone of a Lean transition, providing an objective, data-driven feedback loop that drives organizational maturity. Unlike subjective Agile project retrospectives, an organization-wide monthly review uses quantitative financial, defect, lead time, and throughput data. It builds trust, trains the workforce in management thinking, and prevents organizational maturity from regressing.

At Corbis in March 2007, an outsized acquisition migration task clogged the system and jumped lead times from 30 to 55 days, which was openly reviewed and discussed during the fourth monthly operations review.

• Hold operations reviews monthly, lasting around two hours.
• Lead the meeting with financial data to emphasize running a business.
• Invite value-stream partners, senior leaders, and external guests to present.
• Keep presentations short, focusing on objective metrics like defect rates, lead time, throughput, and value-added efficiency.
• Capture improvement suggestions as management action items and review progress at the next meeting.

Conclusion

Kanban synthesizes the Theory of Constraints, Lean waste reduction, and Deming variability management into an evolutionary framework. You use visual pull systems and work-in-progress limits to catalyze continuous improvement in your technology business without forcing disruptive reorganizations. The method respects your current roles, responsibilities, and processes while introducing mechanisms to expose bottlenecks and systemic failures.

To bootstrap a successful Kanban initiative, you should follow these practical rules:

1. Visualize your current workflow on a board without changing existing roles or titles.
2. Limit work-in-progress strictly at every state transition to expose operational bottlenecks and queue bloat.
3. Establish a pull system where downstream capacity authorizes upstream work replenishment.
4. Define explicit process policies so that team members share a common understanding of done.
5. Manage flow and measure lead times continuously using cumulative flow diagrams and control charts.
6. Implement feedback loops and cadence meetings to inspect system performance and drive evolutionary change.

10 Key Ideas

1. A kanban system regulates workflow by circulating a fixed number of signal cards that restrict work-in-progress, preventing team overload and aligning incoming demand with actual delivery throughput.
2. A technical manager inheriting an existing team should follow a strict six-step sequence that moves from areas under sole managerial control to broader cross-functional collaboration.
3. Starting with Kanban requires changing as little as possible about current roles, job titles, and workflow to minimize resistance and avoid disrupting professional pride.
4. Kanban decouples prioritization, development, and delivery cadences from one another, replacing rigid time-boxed iterations with on-demand flow and structured replenishment meetings.
5. WIP limits should be chosen by consensus with stakeholders to ensure commitment and avoid misusing the system under stress.
6. Work can be categorized into Expedite, Fixed Delivery Date, Standard, and Intangible classes of service to balance urgency and long-term value.
7. Tracking WIP using a cumulative-flow diagram allows teams to monitor day-to-day WIP limits and scan horizontally to read average lead times.
8. Large projects require two-tiered boards to manage coarse-grained requirements, while the monthly Operations Review provides an objective data-driven feedback loop that drives organizational maturity.
9. Kanban acts as a permission giver that liberates teams from rigid software development methodologies and practice-based maturity models, empowering them to evolve a unique process tailored to their context.
10. Kanban implementation boundaries should align with the team's immediate span of political control, negotiating interactions without forcing external departments to change.