Lean Software Development

Lean"Lean" gets used loosely in software conversations — sometimes meaning Kanban boards, sometimes meaning startups moving fast, sometimes just meaning "not much process." Lean Software Development is a specific, named body of thinking with a specific origin, and it is worth separating from its lookalikes.

Origin: From the Toyota Production System to Software

MaryMary and Tom Poppendieck set out the ideas in Lean Software Development: An Agile Toolkit, published in 2003¹. Mary Poppendieck had worked inside manufacturing operations run on the Toyota Production System, and the book's central move is to take principles developed for physical manufacturing — where the enemy is waste in a factory process — and translate them, carefully, into principles for software teams, where the "waste" is less visible but no less real.

The Seven Principles

TheThe Poppendiecks organise the book around seven principles, each paired with a set of practical "thinking tools":

Principle	What it means in software terms
Eliminate waste	Anything that doesn't add customer value is waste: partially done work, extra features nobody asked for, task-switching, handoffs, unclear requirements, defects, bureaucratic process
Amplify learning	Short iterations with real feedback teach a team what the customer actually needs faster than long specification documents can
Decide as late as possible	Keep options open and commit to irreversible decisions at the last responsible moment, when you have the most information
Deliver as fast as possible	Fast delivery is itself a form of learning and of waste elimination — inventory (unshipped work) is a cost, not an asset
Empower the team	People closest to the work should make the decisions about the work, rather than have decisions pushed down from a separate planning function
Build integrity in	Quality, coherence, and usability have to be designed in throughout, not inspected in at the end
See the whole	Optimising one part of a system (one team's throughput, one stage's efficiency) at the expense of the overall flow makes the whole system worse

None of these are unique to software — that is the point. They are lean manufacturing principles, most closely associated with the Toyota Production System, restated for a domain where the "product" is intangible and the "line" is a team of people making decisions rather than a physical assembly line.

Related but Distinct: Kanban

LeanLean Software Development and Kanban are often mentioned in the same breath, and for good reason: both trace back to the same source, Toyota's production system. But they are not the same thing, and conflating them causes real confusion.

• Kanban is a specific, narrow mechanism: a pull-based scheduling system using visual signals (cards, board columns, work-in-progress limits) to control the flow of work through a process, adapted for knowledge work primarily by David J. Anderson.
• Lean Software Development is the broader set of principles above — a way of thinking about waste, learning, and flow that Kanban happens to be a very good practical instrument for, but which does not require a kanban board specifically to apply.

A useful way to hold the two apart: Kanban tells you how to schedule and limit work in progress; Lean Software Development tells you why that scheduling matters and what other waste to look for beyond queue length.

Related but Distinct: Lean Startup

TheThe second common confusion is with "Lean Startup," a separate methodology from a separate author addressing a separate problem. Eric Ries's book The Lean Startup (2011) is about a specific and different question: how does a new venture find a viable product and business model under extreme uncertainty, before it has established what to build at all²? Its core ideas — validated learning as the true unit of progress, the build-measure-learn loop, and the minimum viable product (MVP) as the fastest route through that loop — are aimed at product-market discovery, not at how an existing engineering team organises its delivery process.

Lean Startup does borrow the word "lean" deliberately, in homage to the same Toyota-derived thinking about eliminating waste — in this case the waste of building features or entire products nobody wants. But it is a distinct body of work from Lean Software Development, aimed at a different question (what should we build?) rather than the Poppendiecks' question (how do we build, without waste, once we know?). Students should be able to name both and explain which problem each one solves, rather than treating "lean" as a single undifferentiated label.

References