What is Lean Software Development

Adapted from Lean manufacturing, and specifically the Toyota Production System, to software by Mary and Tom Poppendieck in “Lean Software Development: An Agile Toolkit” (2003). The seven principles below use the names from their 2006 follow-up, “Implementing Lean Software Development”, which renamed five of the originals: amplify learning became create knowledge, decide as late as possible became defer commitment, empower the team became respect people, build integrity in became build quality in, and deliver as fast as possible became deliver fast. Both sets are still in circulation, and they describe the same seven ideas.

Lean Software Development is a principle-based approach that focuses on eliminating waste, optimizing the whole system, and delivering maximum value to customers. Unlike prescriptive frameworks (Scrum, SAFe), Lean provides guiding principles that teams adapt to their specific context.

The goal is impact, not output. Working software nobody uses is waste, regardless of quality.

Core Philosophy:

• Optimize for value delivery, not activity
• Eliminate anything that doesn’t add customer value (waste)
• Make decisions based on learning, not assumptions
• Respect people and empower teams
• Think systemically about the entire value stream

Key Difference from Frameworks:

Lean is not a framework with prescribed ceremonies, roles, and artifacts. It’s a way of thinking about work that asks “Is this adding value?” and “How can we learn faster?” Teams practicing Lean choose practices that serve these principles rather than following a predetermined playbook.

Why Lean Emerged

The problem Lean solves:

Traditional software development (Waterfall, and even Scrum in practice) optimizes for predictability and utilization rather than value and learning. Teams focus on:

• Keeping everyone busy (utilization)
• Hitting velocity targets (activity metrics)
• Completing story points (proxy for value)
• Following the process (ceremonies become rituals)

Lean asks different questions:

• Are we building the right thing?
• How quickly can we learn if we’re wrong?
• What’s preventing faster value delivery?
• Which activities actually add value vs. create waste?

Historical Context

Lean Manufacturing origins (1940s-1950s):

Toyota faced resource constraints post-WWII and couldn’t afford the waste inherent in mass production. Taiichi Ohno developed the Toyota Production System (TPS) based on:

• Just-in-time production (build only what’s needed, when needed)
• Respect for people (workers closest to the work solve problems)
• Continuous improvement (kaizen)
• Elimination of waste (muda)

Adaptation to software (2000s):

Mary and Tom Poppendieck recognized that software development faced similar waste problems:

• Building features nobody uses
• Waiting for approvals and handoffs
• Rework from poor quality
• Context switching and task switching
• Partially done work

They translated Lean Manufacturing principles to software development, creating a principle-based approach rather than a prescriptive methodology.

Philosophy and Values

The Lean Mindset

Lean is about how you think about work, not what ceremonies you practice.

Value-focused thinking:

• Every activity either adds value or creates waste
• Value is defined by the customer, not the team
• Working software that nobody uses is waste, regardless of quality
• The goal is impact, not output

Systems thinking:

• Optimizing individual parts often suboptimizes the whole
• Developers finishing faster doesn’t help if QA is overwhelmed
• Local efficiency creates global bottlenecks
• Focus on end-to-end flow, not individual productivity

Learning-driven decisions:

• Defer commitment until you have information
• Build small experiments to validate assumptions
• Measure actual outcomes, not proxy metrics
• Fail fast and learn quickly

Respect for people:

• People closest to the work understand it best
• Trust teams to make decisions
• Leadership removes obstacles rather than commands actions
• Sustainable pace prevents burnout and maintains quality

Lean vs. Traditional Thinking

What Lean Is NOT

Lean is not:

• About doing more with less (that’s just cutting resources)
• A way to work people harder or eliminate “slack time”
• A prescriptive framework with mandatory practices
• Focused solely on efficiency (value matters more than speed)
• A tool for management to control teams

Lean is:

• A way to eliminate activities that don’t add value
• A philosophy that creates sustainable pace through waste elimination
• A set of principles teams adapt to their context
• Focused on learning and delivering the right thing
• A tool for teams to improve their own systems

The Seven Principles

Lean Software Development is built on seven core principles. Each principle addresses specific sources of waste and provides guidance for creating value.

Principle 1: Eliminate Waste

What it means:

Waste (muda) is any activity that consumes resources but doesn’t add value for the customer. The first principle is to identify and eliminate waste ruthlessly.

The Seven Wastes in Software Development:

1. Partially Done Work

• Code written but not tested
• Features implemented but not deployed
• Design documents that never become code
• Pull requests waiting for review

Why it’s waste: Work that’s not in production isn’t delivering value. It also degrades over time (code conflicts, requirements change, context is lost).

2. Extra Features

• Features built “just in case” someone needs them
• Gold-plating beyond requirements
• Speculative functionality
• Features that looked good in planning but nobody uses

Why it’s waste: Building features nobody uses consumes resources that could deliver actual value. Even worse, extra features create maintenance burden forever.

3. Relearning

• Forgetting what you learned because of delays
• Poor documentation forcing rediscovery
• Knowledge loss when people leave
• Re-solving problems you solved before

Why it’s waste: Learning is expensive. Relearning the same thing wastes that investment.

4. Task Switching

• Context switching between multiple projects
• Interruptions breaking flow
• Working on too many things simultaneously
• Starting new work before finishing current work

Why it’s waste: Every context switch has a cognitive cost. Focus on finishing over starting.

5. Waiting

• Waiting for code reviews
• Waiting for approvals
• Waiting for other teams or dependencies
• Waiting for answers from stakeholders
• Waiting for builds and deployments

Why it’s waste: Time spent waiting is time not delivering value. Delays also increase batch sizes and reduce learning.

6. Handoffs

• Requirements → Design → Development → QA → Ops
• Each handoff loses context and introduces delays
• Misunderstandings at boundaries
• Finger-pointing when something goes wrong

Why it’s waste: Every handoff introduces delay, communication overhead, and loss of context. Cross-functional teams reduce handoffs.

7. Defects

• Bugs discovered late in development
• Production incidents
• Rework and bug fixes
• Technical debt requiring future remediation

Why it’s waste: Finding and fixing defects costs far more than preventing them. Defects also delay valuable work and erode customer trust.

How to Eliminate Waste:

• Make waste visible: Use value stream mapping to see where time and effort go
• Question everything: “Does this add value for the customer?”
• Start small: Pick one waste type and reduce it systematically
• Measure flow: Track cycle time and lead time to identify bottlenecks
• Empower teams: People doing the work can identify waste better than managers

Red Flags:

• Work sits “done” waiting for deployment
• Features ship but nobody uses them
• Code reviews take days or weeks
• Teams work on 5+ things simultaneously
• Significant rework after testing or integration
• Requirements documents written months before development

Principle 2: Build Quality In

What it means:

Quality is not inspected in at the end; it’s built into the process from the beginning. Preventing defects is cheaper and faster than finding and fixing them.

Traditional approach (Quality Inspection):

Development → QA finds bugs → Fix bugs → Re-test → Repeat
↓
Slow feedback, late discovery, expensive fixes

Lean approach (Quality Built-In):

TDD → Pair Programming → Continuous Integration → Automated Testing → Continuous Deployment
↓
Fast feedback, early discovery, cheap prevention

Practices That Build Quality In:

Test-Driven Development (TDD):

• Write tests before code
• Tests define expected behavior
• Code that passes tests is “done”
• Prevents defects rather than finding them

Pair Programming:

• Two developers at one workstation
• Continuous code review
• Knowledge sharing
• Fewer defects introduced

Continuous Integration (CI):

• Merge code frequently (multiple times per day)
• Automated builds and tests
• Fast feedback on integration issues
• Prevents merge hell and integration surprises

Automated Testing:

• Unit tests, integration tests, end-to-end tests
• Run automatically on every commit
• Catch regressions immediately
• Enable confident refactoring

Incremental Development:

• Build in small increments
• Validate each increment before moving on
• Catch mistakes early when context is fresh
• Reduce risk through smaller changes

Why This Works:

Cost of defects increases with time:

• Caught during development: Minutes to fix
• Caught during testing: Hours to fix
• Caught in production: Days to fix (plus customer impact)

Quality built in creates speed:

• Less rework means faster delivery
• Confidence enables moving fast
• Automated tests enable refactoring
• Small batches reduce integration risk

How to Build Quality In:

• Adopt TDD incrementally (start with critical paths)
• Implement CI/CD pipeline (automate builds and tests)
• Reduce batch size (merge code multiple times per day)
• Automate repetitive testing (free humans for exploratory testing)
• Make quality everyone’s responsibility (not just QA)

Red Flags:

• QA team is bottleneck (testing happens after development)
• Manual testing for every release
• “Code complete” but testing takes weeks
• Bugs discovered in production regularly
• Fear of refactoring because tests don’t exist
• “QA will catch it” mindset during development

Principle 3: Create Knowledge

What it means:

Software development is primarily a learning activity, not a manufacturing activity. Treat development as a process of discovery where you gain knowledge through experimentation and feedback.

Development is learning:

• Requirements emerge through building and feedback
• Technical solutions are discovered through experimentation
• Best designs emerge from trying multiple approaches
• Assumptions must be validated with real users

How to Create Knowledge:

1. Short Iterations for Rapid Feedback

Build in small increments and gather feedback quickly:

• Deploy frequently (daily or weekly, not quarterly)
• Release MVPs to validate assumptions
• Conduct user testing early and often
• Measure actual usage, not projected usage

2. Documentation When It Adds Value

Document what’s valuable, skip the rest:

• ✅ Architecture decision records (why, not just what)
• ✅ Runbooks and operational guides (reduce incidents)
• ✅ API documentation (enables integration)
• ❌ Detailed requirements specs (stale before development starts)
• ❌ Exhaustive design docs (code is the design)

3. Code Reviews and Retrospectives

Learning happens through reflection and collaboration:

• Code reviews spread knowledge across team
• Retrospectives identify process improvements
• Post-mortems turn incidents into learning
• Pairing transfers knowledge in real-time

4. Experimentation and Spikes

Validate unknowns through time-boxed exploration:

• Technical spikes (can this API do what we need?)
• Design spikes (which approach feels better?)
• User research (do users actually want this?)
• A/B testing (which version performs better?)

5. Fail Fast and Learn

Failure is information, not waste:

• Small experiments fail cheaply
• Fast feedback reveals wrong directions quickly
• Learning from failure prevents bigger failures
• Psychological safety enables honest experimentation

Knowledge Management Practices:

Architecture Decision Records (ADRs):

• Capture why decisions were made, not just what
• Preserve context for future developers
• Prevent relitigating settled decisions
• Enable learning from past choices

Blameless Post-Mortems:

• Treat incidents as learning opportunities
• Focus on systems and processes, not individuals
• Identify root causes and prevention strategies
• Share learnings across organization

Red Flags:

• Building features without validating user need
• Months of development before first user feedback
• Repeating the same mistakes (no learning from failures)
• Extensive upfront documentation that never gets updated
• Decisions made without data or validation
• Teams afraid to try new approaches (no experimentation)

Principle 4: Defer Commitment

What it means:

Delay irreversible decisions until you have enough information to make them well. Keep options open as long as possible. Don’t commit to a specific approach until the last responsible moment.

Why defer commitment:

Early decisions are based on assumptions:

• You don’t know what you don’t know yet
• Requirements evolve as you learn
• Technical constraints emerge during development
• User needs become clear through usage, not speculation

Early commitment creates waste:

• Building the wrong thing (committed before validation)
• Rework when reality contradicts assumptions
• Missed opportunities (locked into suboptimal path)
• Resistance to change (sunk cost fallacy)

Options-Based Thinking:

Instead of committing early, create options and keep them open:

Traditional approach:

• Month 1: Decide on architecture and technology stack
• Month 2-6: Build according to plan
• Month 7: Discover architecture doesn’t scale
• Result: Expensive rework or living with poor decision

Lean approach:

• Week 1: Build MVP with simplest possible architecture
• Week 2-4: Validate with users, measure performance
• Week 5: Based on data, choose appropriate architecture
• Result: Informed decision based on real information

Last Responsible Moment:

Defer commitment until delaying further would eliminate options or create more risk.

• Too early: Choosing a database before understanding data access patterns
• Too late: Choosing a database after writing thousands of queries
• Last responsible moment: Choosing a database after prototyping data model and access patterns, before implementing full schema

How to Defer Commitment:

1. Flexible Architecture

Design systems that accommodate change:

• Use interfaces and abstractions
• Avoid premature optimization
• Modular components that can be replaced
• Keep options open (don’t lock into vendors early)

2. Just-in-Time Decision Making

Make decisions when you have information:

• Don’t decide technology stack until you understand requirements
• Don’t commit to detailed designs until you’ve prototyped
• Don’t scale infrastructure until you have real traffic patterns
• Don’t hire for specific needs until needs are validated

3. Set-Based Design

Explore multiple approaches in parallel:

• Prototype 2-3 architectural approaches
• Evaluate based on actual implementation learnings
• Choose the best option based on evidence
• Discard alternatives only after validation

4. Evolutionary Design

Let design emerge through refactoring:

• Start with simplest design that works
• Refactor as understanding grows
• Don’t over-engineer for future needs
• Let patterns emerge from usage

Practical Examples:

Microservices vs. Monolith:

• ❌ Commit to microservices architecture on day one
• ✅ Start with modular monolith, split services as scaling needs emerge

Cloud Provider:

• ❌ Commit to AWS and tightly couple to AWS-specific services
• ✅ Use portable abstractions, defer commitment until traffic patterns are clear

Database Technology:

• ❌ Choose database technology based on resume-driven development
• ✅ Prototype with simple relational DB, evaluate alternatives when patterns emerge

Red Flags:

• Months of architecture planning before writing code
• Technology choices made before understanding requirements
• Detailed designs created before any prototyping
• Resistance to changing decisions even when evidence contradicts them
• “We’ve already decided” when new information emerges
• Over-engineering for speculative future needs

Principle 5: Deliver Fast

What it means:

Speed up the delivery of value to customers. Fast delivery creates competitive advantage, enables rapid learning, and reduces risk through smaller batches.

Why speed matters:

Competitive advantage:

• First to market captures mindshare
• Faster response to customer needs
• Outpace competitors through rapid iteration

Faster learning:

• Validate assumptions quickly
• Discover problems while context is fresh
• Pivot based on real feedback, not speculation

Reduced risk:

• Smaller changes are safer
• Faster feedback catches mistakes early
• Less time for requirements to become stale

How to Deliver Fast:

1. Small Batches

Reduce batch size at every stage:

Large batches (slow):

• Deploy 100 features every quarter
• Each deployment is high-risk and stressful
• Bugs affect many features at once
• Difficult to isolate problems

Small batches (fast):

• Deploy 1-5 features every day
• Each deployment is low-risk and routine
• Bugs affect limited scope
• Easy to identify and fix issues

Benefits of small batches:

• Faster feedback (hours, not months)
• Lower risk (smaller changes)
• Easier debugging (fewer variables)
• Higher quality (focus and attention)

2. Limit Work in Progress (WIP)

Finish before starting, and pull new work only when capacity exists. How to set and enforce the limits is covered under Limiting Work in Progress below.

3. Fast Feedback Loops

Compress feedback cycles at every level:

Code level:

• TDD: Seconds between writing test and seeing result
• CI: Minutes between commit and build feedback
• Automated tests: Minutes to validate changes

Feature level:

• Deploy daily or multiple times per day
• Release behind feature flags for gradual rollout
• Measure actual usage immediately
• Gather user feedback within hours/days

Product level:

• Release MVPs to validate direction
• A/B test new features
• Measure outcomes, not outputs
• Pivot based on what usage actually shows

4. Continuous Deployment

Automate deployment to remove delays:

Manual deployment (slow):

• Week-long release cycles
• Extensive manual testing
• Deployment is an event (stressful)
• Rollback is expensive

Continuous deployment (fast):

• Deploy on every commit (if tests pass)
• Automated testing provides confidence
• Deployment is routine (boring)
• Rollback is trivial (automated)

5. Remove Wait States

Identify and eliminate waiting:

• Code reviews taking days → Pair programming or async review within hours
• Waiting for approvals → Empower teams to deploy
• Waiting for other teams → Cross-functional teams reduce dependencies
• Waiting for builds → Faster CI infrastructure

Red Flags:

• Deployment happens monthly or quarterly
• Multiple features bundled into single release
• Long code review queues (days or weeks)
• Manual testing and deployment steps
• Teams working on 10+ items simultaneously
• “It’s done but waiting for deployment”

Principle 6: Respect People

What it means:

Empower teams and individuals to make decisions, solve problems, and continuously improve. Respect means trusting people to do their jobs and providing the context and autonomy they need to succeed.

What respect means in Lean:

Trust:

• Teams closest to the work make the best decisions
• Provide context and constraints, not detailed instructions
• Allow teams to organize their own work
• Support decisions even when you’d choose differently

Autonomy:

• Teams choose their own practices and tools
• Self-organization around problems
• Authority to make technical decisions
• Freedom to experiment and learn

Purpose:

• Clear understanding of why work matters
• Connection between work and customer value
• Transparency about business context and constraints
• Involvement in planning and prioritization

Sustainable Pace:

• No overtime as a standard practice
• Adequate slack time for learning and improvement
• Reasonable workload and expectations
• Prevent burnout through work-life balance

How to Respect People:

1. Empower Teams to Make Decisions

Command-and-control approach:

• Managers dictate how work is done
• Detailed task assignments
• Approval required for decisions
• Teams execute, don’t think

Lean approach:

• Teams decide how to achieve outcomes
• Teams organize their own work
• Authority to make decisions within boundaries
• Teams own the solution, not just execution

2. Provide Purpose and Context

Task-oriented approach:

• “Build feature X”
• No context about why or who it’s for
• Teams are order-takers

Purpose-oriented approach:

• “Users are struggling to find relevant content (here’s the data)”
• “We want to improve content discovery”
• “Here are constraints and success criteria”
• Teams determine the best solution

3. Invest in Learning and Growth

Utilization-focused approach:

• Keep everyone busy 100% of the time
• No slack for learning or improvement
• Training seen as cost, not investment

Growth-focused approach:

• 20% time for learning and improvement
• Conference attendance and training budgets
• Dedicated time for experimentation
• Learning is part of the job, not extra

4. Create Psychological Safety

Blame culture:

• Mistakes are punished
• People hide problems
• Fear prevents experimentation
• CYA behavior dominates

Learning culture:

• Mistakes are learning opportunities
• Problems are surfaced early
• Safe to try new approaches
• Blameless post-mortems focus on systems

5. Remove Obstacles

Manager as controller:

• Assigns tasks and monitors completion
• Evaluates individual performance
• Makes all decisions

Manager as servant leader:

• Removes blockers and impediments
• Provides context and resources
• Facilitates team success
• Enables team autonomy

Red Flags:

• Managers dictate implementation details
• No slack time (100% utilization expected)
• Overtime is standard practice
• People afraid to surface problems or admit mistakes
• Decisions require multiple layers of approval
• Individual performance metrics rather than team outcomes

Principle 7: Optimize the Whole

What it means:

Think systemically about the entire value stream from idea to customer. Optimizing individual parts often suboptimizes the whole. Focus on end-to-end flow, not local efficiency.

Systems Thinking:

Local optimization (common mistake):

• Developers optimize for lines of code written
• QA optimizes for bugs found
• Ops optimizes for system stability (resist changes)
• Result: Suboptimal system performance

Whole system optimization (Lean approach):

• Everyone optimizes for customer value delivered
• Fast flow from idea to production
• Cross-functional collaboration
• Result: Maximum value delivery

The Value Stream:

A value stream is the sequence of activities required to deliver value to customers:

Idea → Prioritization → Design → Development → Testing → Deployment → Usage

Optimizing the whole means:

• Measure end-to-end (idea to customer value)
• Identify bottlenecks in the entire flow
• Don’t push work to bottlenecks (creates pile-ups)
• Increase capacity at bottlenecks, not elsewhere
• Focus on flow, not utilization

Theory of Constraints:

Find the bottleneck:

• Identify the slowest part of your value stream
• Where does work pile up?
• Where are the longest wait times?

Optimize the bottleneck:

• Increase capacity at the constraint
• Remove waste from the bottleneck
• Don’t optimize non-bottlenecks (doesn’t help)

Example:

Value stream analysis reveals:

• Development: 5 days per feature
• Code review: 10 days waiting
• Testing: 3 days per feature
• Deployment: 1 day

Local optimization (wrong):

• Speed up development to 3 days
• Result: Work piles up in code review even faster
• No improvement in overall delivery time

Whole system optimization (right):

• Focus on code review bottleneck
• Add reviewers or pair programming
• Automate tests to reduce testing time
• Result: Faster end-to-end delivery

How to Optimize the Whole:

1. Value Stream Mapping

Map the entire flow from idea to customer, as described under Value Stream Mapping below.

2. Break Down Silos

Create cross-functional teams:

• Teams own entire features (dev → test → deploy)
• Reduce handoffs and wait states
• Shared ownership and accountability
• Communication happens within teams, not between

3. End-to-End Metrics

Measure what matters for the whole system:

Local metrics (misleading):

• Velocity (story points per sprint)
• Bugs found (incentivizes finding bugs, not preventing them)
• Lines of code (incentivizes volume, not value)
• Individual utilization (incentivizes busy-work)

Whole system metrics (useful):

• Lead time (idea to production)
• Cycle time (start to finish)
• Deployment frequency (how often we deliver)
• Mean time to recovery (how quickly we fix issues)
• Customer satisfaction and usage

4. Manage Flow, Not Utilization

Utilization focus (suboptimal):

• Keep everyone busy 100% of the time
• Push work to teams (they’ll figure it out)
• Measure productivity by hours worked

Flow focus (optimal):

• Optimize for smooth flow through the system
• Pull work when capacity exists
• Measure productivity by value delivered
• Accept some idle time (slack enables learning)

5. Continuous Improvement (Kaizen)

Improve the system continuously through small changes, as described under Continuous Improvement below.

Red Flags:

• Teams optimized separately (dev vs. QA vs. ops)
• Developers “throw code over the wall” to QA
• Measuring individual productivity, not team outcomes
• Work piles up between teams (handoff delays)
• Optimizing speed in non-bottleneck areas
• No visibility into end-to-end delivery time

Lean Practices in Action

Lean principles manifest through specific practices that teams adopt based on their context. These practices serve the principles, not the other way around.

Value Stream Mapping

What it is:

A visual representation of the flow of work from idea to customer, including all steps, wait times, and handoffs.

How to create a value stream map:

1. Define the boundaries:

• Start: When does work begin? (idea, requirement, story)
• End: When does value reach customer? (deployed, used, measured)

2. Map the current state:

• List all steps in the process
• Measure lead time (calendar time) at each step
• Measure process time (active work time) at each step
• Calculate wait time (lead time - process time)
• Identify handoffs and decision points

3. Calculate metrics:

• Total lead time: Time from start to finish
• Total process time: Time actually adding value
• Efficiency: Process time / Lead time
• Identify waste: Where is most time spent waiting?

4. Identify improvements:

• Where are the bottlenecks?
• Where is work waiting?
• Which handoffs can be eliminated?
• How can we reduce batch size?

Example value stream map:

Insights:

• Only 22% of time is spent adding value
• 78% of time is spent waiting
• Deployment queue is the biggest bottleneck (10 days)
• Code review creates 4-day delay

How to do this well:

• Involve the entire team (everyone sees the whole system)
• Use actual data (measure real lead times, don’t guess)
• Focus on flow, not blame (systems problem, not people problem)
• Start with one value stream (don’t boil the ocean)
• Revisit regularly (every 3-6 months)

Red flags:

• Value stream map created by manager alone (no team involvement)
• Based on idealized process, not reality
• Never revisited or used to drive improvement
• Used to blame individuals rather than improve system

Kanban Board for Flow Visualization

What it is:

A visual board that shows work moving through stages, with explicit work-in-progress (WIP) limits at each stage.

Why it works:

Kanban makes flow visible and creates pull-based system where work is pulled when capacity exists, not pushed when requested.

Typical Kanban board structure:

| Backlog | Ready | In Progress (WIP: 3) | Review (WIP: 2) | Testing (WIP: 2) | Done |

Key elements:

1. Columns represent workflow stages:

• Customize to your actual workflow
• Include wait states (makes delays visible)
• Keep it simple (too many columns create confusion)

2. WIP limits per column:

• Explicit limit on work in each stage
• Forces finishing before starting
• Makes bottlenecks visible immediately
• Typical starting point: 2 items per person

3. Pull-based flow:

• Work pulled from left to right
• Pull only when capacity exists (WIP limit allows)
• If WIP limit reached, help finish existing work
• Don’t push work to the next stage (let them pull)

4. Explicit policies:

• Definition of “ready” to move to next column
• Definition of “done” for each stage
• Policies for handling blocked work
• Policies for expedited items

How to implement Kanban:

Week 1: Visualize current workflow

• Create board with columns matching actual steps
• Move all current work onto board
• Don’t change anything yet, just visualize

Week 2: Set initial WIP limits

• Start conservative (2x current WIP per column)
• Observe where work accumulates
• Adjust limits based on observations

Week 3: Refine and optimize

• Identify bottlenecks (columns with backed-up work)
• Reduce WIP limits incrementally
• Measure cycle time (start to done)
• Retrospect on what’s improving

Metrics to track:

Cycle Time:

• Time from “In Progress” to “Done”
• Measures how long work takes once started
• Lower is better (faster delivery)

Lead Time:

• Time from “Backlog” to “Done”
• Measures total time including waiting
• Customer-facing metric

Throughput:

• Items completed per week
• Measures delivery rate
• Higher is better (more value delivered)

How to do this well:

• Set WIP limits and enforce them (no exceptions)
• Make policies explicit (everyone knows the rules)
• Track metrics (cycle time, lead time, throughput)
• Retrospect regularly (identify improvements)
• Focus on flow (help unblock work, don’t start new work)

Red flags:

• WIP limits exist but are ignored
• Work piles up in one column (bottleneck not addressed)
• Board doesn’t reflect reality (stale or inaccurate)
• No metrics tracked (can’t measure improvement)
• Starting new work instead of finishing existing work

Continuous Improvement (Kaizen)

What it is:

A practice of making small, incremental improvements continuously rather than waiting for big transformative changes.

Philosophy:

Traditional approach:

• Wait for problems to become crises
• Launch big improvement initiatives
• Disrupt the system with major changes
• Return to status quo after initiative ends

Kaizen approach:

• Identify small improvements constantly
• Make changes incrementally
• Compound small wins over time
• Improvement is part of daily work

How to practice Kaizen:

1. Regular Retrospectives

Weekly or bi-weekly retrospectives:

• What went well? (keep doing this)
• What didn’t go well? (opportunities for improvement)
• What should we try? (small experiments)
• Review previous experiments (did they work?)

Focus on small changes:

• ❌ “We need to completely redesign our architecture”
• ✅ “Let’s reduce our CI build time from 20 minutes to 15 minutes”

2. Empowered to Improve

Everyone can suggest and implement improvements:

• Don’t wait for permission
• Try small experiments
• Share learnings with team
• Leaders remove obstacles

3. Visible Improvements

Track improvements over time:

• Chart cycle time trends
• Celebrate small wins
• Make progress visible
• Build momentum through consistency

4. Blameless Culture

Learn from mistakes:

• Focus on systems, not individuals
• “What about our process allowed this mistake?”
• Prevent recurrence through process improvement
• Psychological safety enables honest reflection

Example Kaizen improvements:

Reducing cycle time:

• Week 1: Cycle time is 12 days (baseline)
• Week 2: Implement async code reviews (cycle time → 10 days)
• Week 4: Add automated linting (cycle time → 9 days)
• Week 6: Set WIP limits (cycle time → 7 days)
• Week 8: Automate deployment (cycle time → 5 days)

Each improvement is small, but they compound.

How to do this well:

• Make improvement part of regular work (not “extra”)
• Focus on small, achievable changes (build momentum)
• Measure results (track metrics over time)
• Celebrate small wins (build culture of improvement)
• Empower everyone to improve (not just managers)

Red flags:

• Retrospectives happen but nothing changes
• Improvements require executive approval
• Focus on big transformative initiatives (ignore small wins)
• Blaming individuals instead of improving systems
• Metrics don’t improve over time (no learning)

Limiting Work in Progress (WIP)

What it is:

Setting explicit limits on the number of items that can be in progress at any given time. Forces teams to finish work before starting new work.

Why WIP limits work:

High WIP (many items in progress):

• Constant context switching (reduces productivity)
• Nothing finishes (everything is “almost done”)
• Long cycle times (everything takes longer)
• Late feedback (nothing reaches completion)
• Hidden bottlenecks (can’t see where problems are)

Low WIP (few items in progress):

• Deep focus (fewer interruptions)
• Fast completion (work finishes quickly)
• Short cycle times (focus accelerates delivery)
• Fast feedback (work reaches completion quickly)
• Visible bottlenecks (immediately obvious)

Theory behind WIP limits:

Little’s Law (queuing theory):

Lead Time = Work in Progress / Throughput

To reduce lead time:

• Reduce WIP (fewer items in progress), OR
• Increase throughput (finish faster)

Usually easier to reduce WIP than increase throughput.

How to set WIP limits:

Start conservative:

• Count current WIP (how many items are “in progress” today?)
• Set initial limit at 1.5x-2x current WIP
• Example: 6 items currently in progress → Set limit at 10

Reduce incrementally:

• After 1-2 weeks, reduce limit by 1-2 items
• Observe impact on cycle time and flow
• Continue reducing until flow becomes constrained
• Find the sweet spot (maximum flow, minimum WIP)

Typical WIP limits:

• Per person: 1-2 items
• Per team: 1.5-2x team size
• Per workflow stage: 2-3 items

What happens when WIP limit is reached:

Option 1: Stop starting, start finishing

• Help colleagues complete in-progress work
• Don’t pull new work until capacity exists
• Focus on unblocking bottlenecks

Option 2: Swarm the bottleneck

• Identify why work is stuck
• Team collaborates to unblock
• Prevent future bottlenecks

How to do this well:

• Set explicit limits (visible to everyone)
• Enforce limits (no exceptions)
• When limit reached, help finish existing work
• Track cycle time (measure improvement)
• Reduce limits incrementally (find optimal point)

Red flags:

• WIP limits exist but are routinely ignored
• “We’re too busy to finish, need to start new work”
• Work sits “in progress” for weeks
• Team working on 10+ items simultaneously
• No improvement in cycle time despite WIP limits

Roles and Responsibilities

Unlike prescriptive frameworks (Scrum has Product Owner, Scrum Master, Development Team), Lean doesn’t define specific roles. Instead, it defines responsibilities that teams organize around.

Core Responsibilities in Lean Teams

1. Cross-Functional Team Members

Responsibilities:

• Own end-to-end delivery (idea → production)
• Collaborate on design and implementation
• Build quality in (testing, code review)
• Continuously improve the system
• Make technical decisions within boundaries

Skills:

• Full-stack capabilities (or specialists who collaborate closely)
• Problem-solving and systems thinking
• Communication and collaboration
• Continuous learning mindset

2. Product/Value Stream Owner

Responsibilities:

• Define and communicate product vision
• Prioritize work based on customer value
• Provide context and business rationale
• Validate outcomes with customers
• Make scope and priority decisions

NOT a gatekeeper or command-and-control manager.

Skills:

• Deep understanding of customer needs
• Business and market knowledge
• Ability to say “no” (prioritization)
• Trust in team’s technical decisions

3. Team Facilitator / Coach

Responsibilities:

• Remove impediments and blockers
• Facilitate retrospectives and improvement
• Coach team on Lean principles
• Protect team from interruptions
• Support team autonomy

NOT a project manager assigning tasks.

Skills:

• Servant leadership mindset
• Understanding of Lean principles
• Facilitation and coaching
• Systems thinking

4. Everyone

Shared responsibilities:

• Identify and eliminate waste
• Suggest and implement improvements
• Respect people and collaborate
• Focus on customer value
• Think systemically about the whole

How Teams Organize

Small, cross-functional teams:

• 5-9 people (whole team fits in two pizzas)
• All skills needed to deliver value
• Self-organizing around work
• Minimize handoffs and dependencies

Stable teams:

• Keep teams together over time
• Build trust and shared context
• Increase effectiveness through familiarity
• Reduce forming/storming overhead

Autonomy within boundaries:

• Clear product vision and priorities (from Product Owner)
• Clear architectural constraints (from architects)
• Team decides how to achieve outcomes
• Authority to make technical decisions

Co-location or strong remote practices:

• Face-to-face communication preferred (when possible)
• Remote teams need strong async communication
• Tools that support collaboration and visibility
• Minimize communication overhead

Implementing Lean

Transitioning to Lean is itself a Lean practice: start small, learn, and adapt based on feedback.

Getting Started with Lean

Don’t: Try to implement all seven principles at once

Do: Start with one principle and expand incrementally

Recommended Starting Point: Eliminate Waste

Week 1: Visualize current state

1. Map your current value stream (idea → customer)
2. Measure lead time and cycle time
3. Identify the biggest source of waste
4. Share with team (make problems visible)

Week 2-4: Reduce one waste

Pick the biggest waste and reduce it:

• If waiting is the problem: Identify bottlenecks, increase capacity
• If task switching is the problem: Set initial WIP limits
• If defects are the problem: Implement automated tests
• If handoffs are the problem: Create cross-functional teams

Week 5-8: Measure and iterate

• Track cycle time and lead time
• Did the change improve flow?
• What’s the next biggest waste?
• Retrospect and adjust

Month 2-3: Add another principle

Once first improvement is stable, add another:

• Build quality in (TDD, CI/CD)
• Deliver fast (reduce batch size)
• Defer commitment (prototyping before committing)

Month 4-6: Expand and refine

Continue adding practices:

• Limit WIP more aggressively
• Implement continuous deployment
• Value stream mapping becomes routine
• Kaizen is part of daily work

Transition from Scrum to Lean

If your team currently uses Scrum:

Keep what works:

• Retrospectives (map to Kaizen)
• Cross-functional teams
• Iterative delivery

Gradually change:

• Replace sprints with continuous flow
• Replace story points with cycle time
• Replace sprint planning with backlog refinement
• Reduce ceremony (standups optional if team doesn’t value them)

Week 1-2: Add Kanban board

• Visualize current sprint work on Kanban board
• Set WIP limits (2x team size initially)
• Continue with sprints for now

Week 3-4: Measure flow

• Track cycle time (how long items take)
• Track lead time (total time including backlog)
• Compare to sprint velocity
• Discuss learnings in retrospective

Week 5-8: Reduce sprint length

• Move from 2-week sprints to 1-week sprints
• Reduces batch size and ceremony overhead
• Get comfortable with frequent delivery

Week 9-12: Transition to continuous flow

• Stop batching work into sprints
• Pull work continuously when capacity exists
• Deploy as soon as work is ready (not waiting for sprint end)
• Retrospectives happen every 2 weeks (not tied to sprints)

Month 4+: Refine Lean practices

• Focus on eliminating waste
• Reduce cycle time incrementally
• Build quality in (TDD, CI/CD)
• Continuous improvement through Kaizen

Common Obstacles and How to Overcome Them

Obstacle 1: “We need detailed estimates for planning”

Problem: Leadership wants estimates and predictability

Solution:

• Track historical cycle time (this is your data)
• Forecast based on throughput (items per week)
• Provide probabilistic estimates (“80% confident we’ll finish in 3-5 weeks”)
• Demonstrate that actual cycle time is more accurate than estimates

Obstacle 2: “Our stakeholders won’t accept continuous delivery”

Problem: Business wants batched releases

Solution:

• Start with continuous deployment to staging
• Release to production on regular cadence (weekly)
• Gradually increase frequency as confidence builds
• Use feature flags for gradual rollout
• Show business value of faster feedback

Obstacle 3: “We have dependencies on other teams”

Problem: Can’t deliver end-to-end without other teams

Solution:

• Map dependencies and make them visible
• Negotiate service-level agreements with other teams
• Build abstractions to reduce coupling
• Gradually reorganize around value streams (long-term)

Obstacle 4: “Our culture is command-and-control”

Problem: Management uncomfortable with team autonomy

Solution:

• Start small with one team (prove the model)
• Show results (faster delivery, higher quality)
• Educate leadership on Lean principles
• Make work visible (transparency builds trust)
• Gradual cultural shift through demonstrated success

Obstacle 5: “We don’t have time to improve”

Problem: Team feels too busy to implement changes

Solution:

• Improvement is an investment that pays back quickly
• Start with smallest possible change (15 minutes per week)
• Track time savings (demonstrate ROI)
• Make improvement part of regular work (not extra)

When to Use Lean

Lean is a way of thinking rather than a process, so what decides its fit is whether a team is in a position to use it. Two conditions do most of that work.

The first is that the team can see its own value stream. Lean’s central move is to look at the whole path from request to running software and find where work waits. A team that cannot see past its own step can eliminate waste locally and make the system slower, which is the failure the seventh principle exists to prevent.

The second is that the team has the autonomy to act on what it finds. Most of the waste in a software value stream sits in handoffs, approvals and queues that a single team does not control. Lean surfaces those quickly, and surfacing a problem nobody is permitted to fix produces cynicism rather than improvement.

Given both, Lean suits environments where efficiency is genuinely constrained and waste is unaffordable, where the product direction is still being validated and learning fast matters more than executing a plan, and where teams are mature enough not to need prescribed structure to function.

Where Lean Fits Badly

Teams new to iterative work. Lean gives principles rather than practices, which assumes enough experience to derive the practices. A team that has never run a feedback loop usually does better starting from something prescriptive and moving to principles once the habits exist.

Command-and-control cultures. Respect people is a principle, not a value statement. If decisions about how work is done sit above the team, most of what Lean asks for is not available, and “Lean” becomes a label for a cost reduction programme.

Fixed-scope contracts. Deferring commitment has little room to operate when scope was agreed in advance and the deliverable is contractual.

Regulated environments needing specified documentation. This is less absolute than it looks, since Lean objects to documentation nobody uses rather than to documentation as such, but a team required to produce artifacts on a schedule has less latitude to call them waste.

Common Adaptations

Lean’s principles sit underneath other methods rather than competing with them, which is why they combine easily. Flow-based delivery is Lean’s own thinking made concrete, with work visualized and limited so that queues become visible. Iterative frameworks gain from Lean’s attention to what happens between the iterations, which is where much of the waiting usually is. And continuous delivery is largely an engineering answer to the deliver-fast principle, since batch size and deployment friction are what determine how quickly anything can reach a user.

Where Lean Goes Wrong

Lean is easier to misread than most methods, because several of its principles have a plausible wrong interpretation that sounds like the right one.

“Eliminate Waste” Read as “Do More With Less”

The most damaging misreading, and the most common. Leadership hears waste elimination and applies it to headcount and slack, and the improvement programme becomes a cost programme.

Waste in Lean is specific. It is work in progress that is not moving, partially done work that has to be reworked, handoffs that lose information, defects that cause rework, task switching, waiting, and features nobody uses. None of these are people, and most are removed by changing how work flows rather than by asking anyone to work harder.

Warning signs: waste framed as utilization, improvement targets stated as cost reduction, and the team’s capacity reduced rather than its queues.

Optimizing Efficiency Without Validating Value

A team can become extremely efficient at producing software nobody wants. Lean counts unused features as waste precisely because building them consumes the whole value stream and returns nothing, so throughput improvements on the wrong work make the waste arrive faster.

This is why create knowledge and deliver fast are separate principles. Speed is only valuable because it shortens the loop back to learning whether the thing was right.

Warning signs: cycle time improving with no measure of whether anything shipped is used, and feature counts reported as outcomes.

Practices Adopted Without the Principles

Boards and WIP limits appear, the vocabulary changes, and nothing underneath does. A board that shows the team’s own steps but none of the waiting between teams makes the visible part of the process look fine while the actual delay is off the board.

Practices are answers to questions the principles ask. Adopted without the question, they become procedure, and procedure is the thing Lean was reacting against.

Warning signs: a board that never changes shape, WIP limits set once and never revisited, and improvements that are all inside one team’s step.

No Measurement

Lean is empirical. Without cycle time, lead time, queue lengths and some measure of outcome, “eliminating waste” is an opinion, and the team cannot tell an improvement from a change.

Measurement also protects the team, since it is what distinguishes a demonstrated improvement from an assertion when someone senior has a theory.

Warning signs: improvements justified by how the work feels, no baseline before a change, and no measure of whether delivered work was used.

Local Optimization

Each step gets faster and the whole gets slower. Development speeds up and the queue for testing grows, so work in progress rises and everything takes longer from end to end.

Optimize the whole exists for this, and it is the principle most often violated by well-intentioned people, because local improvement is what individuals and teams are in a position to do and usually what they are measured on.

Warning signs: step-level metrics improving while end-to-end time does not, teams measured on their own throughput, and growing queues between stages nobody owns.

Lean Used to Increase Control

Value stream mapping makes work visible, and visibility can be used to help or to supervise. Used to monitor individuals, it produces exactly the behavior that makes the data useless, since people optimize what is being watched.

Respect people means the people doing the work are the ones who understand it and are best placed to improve it. Management’s part is removing what is in their way.

Warning signs: metrics reported per person, improvements mandated from above, and teams presenting numbers rather than problems.

Deferring Commitment Becomes Avoiding It

Deciding at the last responsible moment requires identifying when that moment is. Without it, deferral becomes indefinite, decisions accumulate, and work proceeds on an unstated assumption that nobody has agreed to.

The test is whether the team knows what it is waiting for and what will make the decision. Deferring to gather specific information is the principle; deferring because deciding is uncomfortable is not.

Warning signs: decisions with no deadline and no named trigger, work blocked on a choice nobody is making, and options kept open long after the information arrived.

Eliminating Slack

Slack looks like waste and is the opposite. A system running at full utilization has no capacity to absorb variation, so every disruption becomes a delay that propagates, and queues grow.

Slack is also where improvement happens. A team with no unallocated time cannot fix the process that is slowing it down, which locks in whatever it is currently doing.

Warning signs: capacity planned to one hundred percent, improvement work with no time allocated, and delivery times lengthening while utilization looks excellent.