Lean software development: principles, wastes and flow

Lean software development applies lean thinking from manufacturing to building software: remove waste, learn fast and deliver value to customers in a steady flow. It focuses on the whole system, not just coding speed.

Mary and Tom Poppendieck introduced the approach in their 2003 book Lean Software Development: An Agile Toolkit. This guide covers the seven principles, the seven wastes of software, flow metrics, value stream mapping and how lean compares with agile and DevOps.

Key takeaways

Lean software development adapts lean thinking to software and focuses on the flow of value to the customer.

The Poppendiecks describe seven principles, from eliminating waste to seeing the whole.

Typical software wastes include partially done work, extra features, waiting and task switching.

Flow metrics such as lead time and work in progress show where work gets stuck.

Lean, agile and DevOps overlap and work well together rather than competing.

What is lean software development?

Lean software development is a way of running software work that treats waiting, rework and unused features as waste. The goal is to get useful software to users sooner, with fewer defects.

The Poppendiecks drew on the Toyota Production System. They also used earlier lean thinking set out by Womack and Jones in their 1996 book Lean Thinking. They adapted these ideas for a field where the product is code, not physical parts. See our overview of the Toyota Production System for the roots.

Software differs from a factory in that every project is new. Lean software therefore relies on learning, not on repeating a fixed process.

What are the seven principles of lean software development?

The seven principles are eliminate waste, amplify learning and decide as late as possible. The rest are deliver as fast as possible, empower the team, build integrity in and see the whole. The 2003 book framed them in this way.

In 2006 the Poppendiecks published a separate book, Implementing Lean Software Development: From Concept to Cash, with a revised list. Its seven principles are eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people and optimize the whole. Check which book you are reading before you quote a list.

Each principle has a practical meaning, covered in the next two sections.

Principles one to four: waste, learning, timing and speed

Eliminate waste means removing anything that does not add value for the customer. This starts with learning to see the waste, which the next section lists.

Amplify learning means shortening feedback loops. Short iterations, frequent demos and quick user testing all help the team find out sooner what works.

Decide as late as possible means keeping options open until you have enough facts. Make irreversible choices late and reversible ones early.

Deliver as fast as possible means shipping small pieces often. Short cycles cut the delay between an idea and customer feedback.

Principles five to seven: team, integrity and the whole

Empower the team means letting the people who do the work make decisions about how they do it. Managers set direction and remove obstacles.

Build integrity in means designing quality into the product from the start, through testing, clear design and automation, rather than inspecting at the end.

Late defects are expensive. A 2002 NIST study estimated that inadequate software testing infrastructure cost the US economy $59.5 billion a year, and that feasible improvements in testing could save about $22.2 billion of that.

See the whole means improving the entire flow from idea to customer, not one stage in isolation. A faster coding step does little if reviews and releases still queue for days.

What are the seven wastes of software development?

The seven wastes of software development are partially done work, extra features, relearning, handoffs, delays, task switching and defects. This is the list from the Poppendiecks' 2006 book. Their 2003 book mapped the manufacturing wastes more directly and listed partially done work, extra processes, extra features, task switching, waiting, motion and defects.

Partially done work is code that is written but not released. Extra features are functions that nobody uses but that still need maintenance.

Relearning is rediscovering knowledge the team already had. Handoffs lose information between people. Delays hold up decisions and releases.

Task switching drains attention across too many projects. Defects need rework and erode trust. Compare this list with the eight wastes of lean manufacturing.

How do flow metrics and value stream mapping help?

Flow metrics and value stream mapping show where work waits, so you can fix the biggest delays first. Both make invisible queues visible.

Useful flow metrics include lead time, the time from request to delivery, and work in progress, the number of items started but not finished. Say a change takes 10 days from request to release, but only 2 days are active work. The other 8 are waiting. These numbers are illustrative.

A value stream map for software traces each step from idea to production, noting active time and wait time. Our guide to value stream mapping explains the method, and the flow metrics tools category covers related software.

Limiting work in progress helps flow. A kanban board makes that limit visible, as described in our guide to kanban project management.

A worked example: one feature from request to release

This example is illustrative. A team traces one small feature through its steps and records active time and waiting time for each.

Request to start: 6 days waiting in the backlog, 0.5 days of refinement. Build: 2 days of coding, then 1.5 days waiting for review. Review: 0.5 days. Test: 1 day waiting for a test environment, 0.5 days of testing. Release: 3 days waiting for the weekly release window, then 0.5 hours to deploy.

Lead time is about 15.5 days. Active work is about 3.5 days, so flow efficiency is about 3.5 ÷ 15.5, or roughly 23%. Most of the delay sits in the backlog and the release window, not in coding.

The team picks the largest wait it controls. Moving from a weekly release window to releasing whenever a change passes its tests removes up to 3 days from every feature, which a faster coder could never match. The flow efficiency calculator runs the same arithmetic on your own numbers.

How do teams apply the principles day to day?

Teams apply the principles through small, repeatable habits: limiting work in progress, finishing before starting, and reviewing flow often. Each habit maps to one or more of the seven principles.

Eliminate waste: hold a short review of the backlog and drop requests nobody has asked about for months. Unused features cost maintenance time.

Amplify learning: demo work to real users every week, and note what surprised the team. Decide as late as possible: choose a database or vendor only when the first feature truly needs it.

Deliver as fast as possible: split a large feature into slices that each reach users. Empower the team: let the people doing the work set their own working limits.

Build integrity in: write automated tests alongside code, so quality is not left to a final check. See the whole: invite operations and support staff to planning, so delays beyond the code become visible.

Breaking a request into testable assumptions

Lean across the software lifecycle

How do you measure flow in software delivery?

Measure flow with four numbers: lead time, cycle time, work in progress and throughput. Together they show how fast work moves and where it waits.

Lead time runs from the customer's request to delivery. Cycle time runs from the moment work starts to the moment it is done. The gap between them is time spent waiting in the backlog.

Work in progress counts items started but not finished. Throughput counts items finished in a period, such as a week.

These figures are linked by Little's Law, which says average work in progress equals throughput multiplied by cycle time. Try it with our Little's Law calculator. Say a team finishes 5 items a week and holds 20 in progress. Average cycle time is then 4 weeks. The numbers are illustrative.

If you want shorter cycle time, the law shows you can cut work in progress. Track the trend over weeks rather than judging a single week. Software in the flow metrics tools category can chart these measures automatically.

Four kinds of measure to balance

What is the difference between lean, agile and DevOps?

Lean is a set of principles about value and waste. Agile is a set of values and practices for iterative delivery. DevOps links development and operations to release reliably. They overlap and support each other.

Lean asks what creates value and removes the rest. Agile, based on the 2001 Agile Manifesto, emphasizes working software, collaboration and response to change.

DevOps, sometimes called lean DevOps when it stresses flow and waste, focuses on automation and shared ownership between development and operations. Our lean agile software hub covers the tools that bring these together.

The three differ in scope. Agile mostly governs how a team plans and builds in short cycles. DevOps mostly governs how code reaches production and stays healthy there. Lean looks across both, from idea to customer.

Here is an illustrative case. An agile team ships every two weeks, but releases wait four days for a manual approval. Lean flags that wait as waste, and a DevOps practice such as automated testing removes it.

Lean also adds a question the others do not always ask: is this work worth doing at all? Cutting an unused feature beats speeding it up.

That question matters because many ideas don't pay off. In Harvard Business Review, Ron Kohavi and Stefan Thomke report that at Microsoft about one-third of tested ideas prove effective, one-third have neutral results and one-third have negative results.

In practice, many teams use agile ceremonies, lean thinking about flow and DevOps automation at once.

Research on software delivery keeps returning to lean basics. Google's 2024 DORA report found that rising AI adoption came with an estimated 1.5% drop in delivery throughput and a 7.2% drop in delivery stability, and the DORA team concluded that basics such as small batch sizes and robust testing remain crucial.

Habits that keep lean practical

Mistakes when adopting lean in software

A ten-point lean software check

How do you start with lean software development?

Start by mapping how one piece of work moves from idea to release, then pick the largest delay and improve it. Small, visible steps build support better than a large program.

A simple start is:

1. Map one recent feature from request to production.

2. Mark the waiting time between steps.

3. Set a limit on work in progress.

4. Review the flow weekly and adjust.

The same thinking applies to design work, as our guide to lean UX shows. For software that tracks delivery flow, see the value stream management software category.

Frequently asked questions