Picture a team with eleven things ‘in progress’ and four developers. Nothing had shipped in seven weeks. Everyone was busy. Nobody could point at anything finished.

That’s not a coding problem. That’s a flow problem, and it’s the one lean software development was built to solve.

The idea is simple enough to explain in a sentence: strip out anything that doesn’t add value for the person paying for the software. Applying it is harder, which is why this guide covers the seven principles, what’s changed now that AI writes a chunk of everyone’s code, and a 90-day way in.

What Is Lean Software Development?

It started on a factory floor, which is either reassuring or alarming depending on how you feel about factories.

Taiichi Ohno built the Toyota Production System from the 1940s onward. Toyota sat on it as a trade secret until the late seventies. Thirty years of advantage, and it came from process rather than technology.

There’s a detail in the origin story people skip. Ohno got the Kanban idea from wandering around American supermarkets. Shoppers pull items off a shelf, staff restock only what’s been taken, and nothing rots in a stockroom waiting for demand that never comes. Your project board has columns because of a grocery aisle.

Mary and Tom Poppendieck carried all this into software in 2003 with Lean Software Development: An Agile Toolkit. Mary had worked in manufacturing before she worked in software. She looked at waterfall, compared it to what she already knew, and concluded the factory had solved this better.

Their sharpest line is still the one worth remembering. Development is “an exercise in discovery.” Manufacturing is “an exercise in reducing variation.” Two different jobs. You can’t manage them with the same playbook.

The Seven Wastes of Software Development

Lean calls waste muda. On a real project it shows up like this:

Waste type What it actually looks like
Partially done work Three features at 80%. None of them live.
Extra features Someone asked once, in a meeting, in April.
Relearning The only person who understood that module has left.
Handoffs Dev finishes Tuesday. QA picks it up Monday.
Task switching Two projects, one developer, roughly half the output.
Delays Waiting on approvals, environments, a client decision.
Defects Bugs caught by users instead of by the pipeline.

Read that list against your own last quarter. Most teams find they lose far more time to waiting than to writing code, and it’s uncomfortable the first time you see it in numbers.

There’s a famous statistic here: the Standish Group reported that 45% of software features are never used, with another 19% barely touched. Fair warning, Mike Cohn has publicly questioned how that data was gathered, and he has a point. Treat the exact number with suspicion. The underlying pattern holds up fine.

The 7 Principles of Lean Software Development

Seven principles, and one thing you can actually do about each.

Eliminate waste. Map how work moves from idea to production, on a whiteboard, with everyone in the room. Then count the waiting. That number is usually the shock.

Build quality in. Quality isn’t a phase near the end. It’s automated tests, code review and continuous integration running from week one. Skip this and everything else on the list stops working.

Amplify learning. Show a working screen instead of writing a forty-page spec. People react to things they can click.

Delay commitment. Decide at the last responsible moment, because you’ll know more then than you do today. Note the word responsible. This isn’t an excuse to avoid decisions.

Deliver fast. Small releases give you feedback. Big releases give you a nasty surprise on launch day.

Respect people. The developers know the details. Routing every decision through someone who doesn’t just adds a queue.

Optimize the whole. Speed up one stage and you’ve moved the bottleneck, not removed it. Go find the slowest step in the whole system and fix that instead.

You’ll see different wording elsewhere. Build integrity in and build quality in are the same principle. So are see the whole and optimize the whole. The Scrum Alliance guide sticks with the 2003 phrasing if you want the originals.

Curious what this looks like on a finished build? Have a look through our project portfolio

Lean vs Agile vs Scrum vs Kanban

This trips up nearly everyone, including people who’ve been doing it for years.

Approach What it is Main focus
Agile A philosophy (the 2001 Manifesto) Better products
Lean A whole-system philosophy Better processes
Scrum A framework Fixed sprints, defined roles
Kanban A method Continuous flow, WIP limits

The version that sticks: lean improves how you work, agile improves what you ship. They were never in competition, and most decent teams end up running some blend of the two without naming it.

Small piece of trivia. The Poppendiecks weren’t at the 2001 Snowbird meeting that produced the Agile Manifesto. Lean got adopted into agile after the fact.

What AI Changed

Most guides on this topic were written before any of this mattered, so here’s the update.

Google’s 2025 DORA report surveyed roughly 5,000 technology professionals, and its headline finding is unsentimental: AI is an amplifier. It makes a disciplined team faster and a chaotic team considerably worse.

The two findings sit awkwardly together. AI adoption now correlates with higher throughput, so teams genuinely are shipping more. It also still correlates with lower stability, meaning more failed changes and more rework. More code, arriving faster, into a review-and-test pipeline that was already the narrowest part of the system.

GitClear’s research points the same way. Looking at 211 million lines of code changes, copy-pasted lines climbed from 8.3% in 2020 to 12.3% in 2024, while refactored lines dropped from 24.1% to 9.5%. In 2024, copy-paste overtook refactoring for the first time on record.

In lean vocabulary that’s defect waste and rework waste, both growing.

So no, AI hasn’t retired lean thinking. It’s promoted “build quality in” from good practice to the thing holding everything else together.

How to Measure It

Skip this bit and you’ll never prove anything improved. Four numbers are enough:

Metric What it tells you
Cycle time Days from starting work to it being live
Flow efficiency Active work time ÷ total elapsed time
WIP How many items are open at once
Change failure rate How often a release causes a problem

Take a baseline before you touch anything, otherwise “it feels faster” is all you’ll ever have.

Flow efficiency is the one that hurts. Plenty of teams discover real work happens in under 20% of the elapsed time. Everything else is queueing.

When Lean Is the Wrong Choice

Every article on this subject sells lean as universally correct. It isn’t, and pretending otherwise wastes your time.

Think twice if you’re working under fixed compliance gates where documentation is a legal requirement, or on a fixed-scope fixed-price contract where delaying commitment breaks the agreement you signed. Teams under three people won’t get much from WIP limits either.

The real killer, though, is leadership hearing “eliminate waste” and mentally translating it to “cut staff.” That misunderstanding has ended more lean adoptions than any technical obstacle. Waste means unfinished work and waiting. It has never meant people.

A 90-Day Start

You don’t need a transformation programme, a consultant, or a new tool.

Days 1–30. Map the value stream on one whiteboard. Measure your current cycle time. Count what’s genuinely in progress right now.

Days 31–60. Set a WIP limit and hold it. Finish before starting. Get automated tests onto your riskiest path.

Days 61–90. Re-measure against the baseline, then fix the single worst queue you found.

One bottleneck at a time. That’s genuinely the whole method.

SaaS & ERP Development

Want a team that already works this way?

Our service ships in small, tested increments, so you see working software early rather than six months in.

Explore SaaS & ERP Services Start a Project

FAQs

Is lean software development the same as agile?

No. Lean is a philosophy about the whole system and its processes. Agile is a delivery approach for teams. Lean usually sits as one framework under the agile umbrella.

Is it the same as Lean Startup?

No. Eric Ries’s Lean Startup is about validating a business idea. Lean software development is about how engineering work flows. The two pair well, but they’re separate things.

What are the 7 principles of lean software development?

Eliminate waste, build quality in, amplify learning, delay commitment, deliver fast, respect people, and optimize the whole.

Does lean mean hiring fewer developers?

No, and this is the most common misreading. Lean targets waiting time, rework and unused features. Cutting headcount usually makes waste worse, because work sits in queues longer.

Does lean still work with AI-generated code?

It matters more than it did. DORA’s 2025 data shows AI lifting throughput while lowering stability. Automated testing and fast feedback are what make that speed safe.

Ready to Build Without the Waste?

Back to that team with eleven things in progress. Nothing was wrong with their engineers. There was simply too much started and not enough finished.

We build the way we’d want someone to build for us: small releases, tests from the first week, and no features nobody asked for.

Tell us what you’re trying to build and we’ll tell you honestly whether we’re the right fit.