Software Engineering
Kanban and Lean
2011: Amazon deploys once every 11.6 seconds - 1079 per day. How is this physically possible? The answer: Kanban and Lean. Small tasks, bounded WIP, continuous flow. Each completed task goes to production. No release trains, no sprint ceremonies, no 'merge week'. Just a stream of small, done pieces of work.
- **Toyota Production System**: WIP limits and just-in-time production made Toyota the most profitable auto manufacturer for decades. Lean software directly adapts these principles.
- **Spotify**: adapted Kanban in squad/tribe structures - autonomous teams with their own boards and WIP limits, allowing over 100 concurrent deployments per week.
- **GitHub Flow**: branch -> PR -> merge -> deploy. Maximally simple flow inspired by Lean: minimum overhead, maximum delivery speed.
WIP Limits
Work In Progress (WIP) limit is a constraint on how many tasks can be simultaneously active in a given stage. A WIP limit of 3 for 'In Progress' in a team of five looks strict but works: when the limit is reached, the team helps complete existing tasks instead of starting new ones.
WIP limits create 'swarm behavior': a developer whose column is full joins colleagues on their tasks. This surfaces blockers immediately and reduces context-switching. Toyota's production line used the same principle - never start new work when the current stage is blocked.
A team sets WIP limit 3 for 'In Progress'. A developer finishes a task but the column is full. What is the correct action?
Flow
Flow is the smooth, predictable movement of work through the system without queue buildup and bottlenecks. Kanban optimizes for flow metrics: cycle time (time from start to done for one task) and throughput (tasks completed per unit time). Optimizing individual utilization at the expense of flow is an anti-pattern.
Visualizing the flow is the first step. The Cumulative Flow Diagram (CFD) shows the number of tasks in each column over time. A widening band means tasks enter faster than they exit - a bottleneck. Narrowing indicates the stage is becoming a non-issue.
The 'Code Review' band on the Cumulative Flow Diagram widens sharply over the last three days. What does this indicate?
Continuous Delivery in Kanban
Kanban naturally leads to Continuous Delivery: when tasks complete one at a time in small increments, each completed task can go to production. The Definition of Done (DoD) is a checklist that a task must satisfy before moving to the Done column.
In Kanban there is no concept of 'sprint' or 'release date'. Task done - it can go to prod. The Definition of Done enforces quality gates: code written and pushed, unit tests pass, code reviewed, staging verified, feature flag configured. '90% done' does not exist - a task is either done or not.
A developer says a task is '90% done' and asks to move the card to Done for metrics. What is the correct response?
Lean Principles
Lean Software Development is an adaptation of the Toyota Production System for software. Mary and Tom Poppendieck (2003) identified 7 types of waste (muda) in software: partially done work, extra features, relearning, handoffs, task switching, delays, defects.
The 7 wastes in software development: partially done work (unfinished branches - spent energy, zero value), extra features (64% of features in average product are rarely or never used - STANDISH 2002), relearning (rediscovering decisions already made), handoffs (knowledge loss at each handoff), task switching (context switch costs 20+ min of cognitive recovery), delays (waiting for review, approval, environment), defects (bugs found late cost 30x more to fix than at commit time).
Kanban and Scrum are mutually exclusive - you must choose one
Kanban and Scrum can be combined (Scrumban). Kanban is a flow management system, Scrum is a framework for iterative delivery. Many teams use Scrum ceremonies (planning, retro) with Kanban WIP limits and flow metrics.
Methodologies are tools, not religions. Scrumban emerged because teams found value in elements of both. The goal is delivering value reliably, not methodology purity.
A product manager asks to add a feature 'just in case, it might be needed later'. From a Lean perspective, this is:
Key Ideas
- **WIP Limits**: constraining parallel work creates pressure to complete rather than start - the team works as one unit, not isolated individuals.
- **Flow**: optimizing flow (cycle time, throughput) matters more than maximizing individual utilization - bottlenecks are visible through CFD.
- **Lean**: eliminating 7 wastes (muda) - unfinished work, extra features, task switching, delays, defects - each waste is quantifiable and addressable.
Related Topics
Kanban and Lean form the foundation for modern delivery practices:
- CI/CD Pipeline — Technical implementation of Continuous Delivery - automation that makes frequent small deployments safe and sustainable
- Git Flow and Branching Strategies — Trunk-based development is the Git practice that implements Lean's minimum WIP principle at the version control level
Вопросы для размышления
- If a team never reaches the WIP limit, does that mean the system works perfectly or that the limit is set too high?
- Which types of Lean waste (muda) are most common in software teams you have worked with?
- How does Kanban actually differ from Scrum in work management - and when is each preferable?