Poppendieck’s Principles are seven principles of Lean Software Development published by Mary and Tom Poppendieck in 2003, in a book titled Lean Software Development: An Agile Toolkit, which accomplished the rare feat of translating Toyota Production System wisdom into software practices without losing the wisdom in translation.
This distinguishes the Poppendiecks from approximately 97% of all subsequent Lean-to-software translators, who translated the vocabulary without the discipline, the kanban boards without the WIP limits, and the andon cord without the permission to pull it. The Poppendiecks translated the thinking. This made the book important and the consulting industry nervous.
“Most people who say they do Lean have read a blog post about Lean. The Poppendiecks actually read Toyota.”
— A Passing AI, reviewing the bibliography
The Seven Principles
Mary and Tom Poppendieck distilled Lean software development into seven principles. They are stated here as the Poppendiecks stated them, because they got them right the first time and subsequent restatements have only added noise:
1. Eliminate Waste — anything that doesn’t add value to the customer is waste. Extra features, waiting, handoffs, defects, task switching, partially done work. All of it. Muda.
2. Amplify Learning — development is a learning process, not a production process. Short feedback loops. Iterate. The code teaches you what the code should be.
3. Decide as Late as Possible — delay commitment until the last responsible moment, when you have the most information. Not the last possible moment — the last responsible moment. The distinction matters and is routinely ignored.
4. Deliver as Fast as Possible — speed enables learning. Short cycles compress feedback. The faster you ship, the faster you learn, the less you waste.
5. Empower the Team — the people doing the work make the decisions about the work. Not the committee. Not the advisory board. Not the Vice President of Deciding Things on Behalf of People Who Already Know the Answer.
6. Build Integrity In — quality is built in, not inspected in. Refactor continuously. Do not accumulate technical debt and call it velocity.
7. Optimize the Whole — don’t sub-optimize parts at the expense of the whole system. A fast database query inside a slow system is a fast component of a slow product. The customer does not experience your component. The customer experiences the system.
Seven principles. They fit on a napkin. They have been confirmed by every successful software project and violated by every unsuccessful one. They are not enough to sustain a certification industry, which is how you know they are correct.
The Translation That Didn’t Lose the Signal
The Poppendiecks accomplished something that the Lean-to-software pipeline normally makes impossible: they translated manufacturing principles into software principles without committing the category error that ruins most such translations.
The category error is this: manufacturing produces identical widgets; software produces unique solutions. A Toyota factory makes the same Corolla ten thousand times. A software team makes one thing, once, and then changes it forever. Most Lean-to-software translations founder on this reef — they treat development as production (make the widgets faster!) when it is actually product development (learn what the widget should be).
The Poppendiecks understood this. Their principles don’t say “produce faster.” They say “learn faster.” They don’t say “eliminate defects from the production line.” They say “build quality into the learning process.” The shift from production metaphor to learning metaphor is the entire contribution, and it is the part that subsequent frameworks dropped first.
The Lean article on Lean covers Taiichi Ohno and the Toyota Production System in appropriate depth. This article concerns itself with what happened when two people who understood both Toyota and software sat down and asked: what does this actually mean for code?
Principle 1: Eliminate Waste — YAGNI’s Parent
Every unnecessary thing is waste. The Poppendiecks identified seven wastes in software, mapped directly from Ohno’s seven wastes in manufacturing:
| Toyota Waste | Software Waste | Field Example |
|---|---|---|
| Overproduction | Extra features | The plugin system for one plugin |
| Inventory | Partially done work | Branches that exist for six months |
| Transportation | Handoffs | “The other team will integrate it” |
| Motion | Task switching | Four projects, zero progress |
| Waiting | Delays | Blocked on the change advisory board |
| Over-processing | Extra process | Fourteen approval gates for a CSS fix |
| Defects | Defects found late | Bugs discovered in production that were introduced in sprint 3 |
This is YAGNI’s parent. YAGNI says “don’t build what you don’t need.” Poppendieck says “don’t build what you don’t need, and also don’t wait for what you could have now, and also don’t hand off what you could own, and also don’t switch between things when you could finish one.” YAGNI is one flavour of waste elimination. Poppendieck is the whole menu.
Every AbstractSingletonProxyFactoryBean is muda. Every meeting that could have been an email is muda. Every feature built on speculation rather than demand is muda. The Squirrel’s entire output is muda, though it prefers the term “architectural investment.”
Principle 3: Decide as Late as Possible — The Lizard’s Business Case
Principle 3 is the one that connects to everything.
Decide as late as possible. Not as late as you can get away with — as late as responsible. The last responsible moment is the point at which failing to make a decision eliminates an important alternative. Before that moment, every commitment is a bet placed with insufficient information.
This is pure Patience. The Lizard has been practising Principle 3 for 400 million years, sitting on warm rocks and declining to commit to an architecture until the simple system has revealed what it cannot do. The Lizard does not call it “the last responsible moment.” The Lizard calls it “not yet.” The effect is identical.
This is also pure Gall’s Law. Don’t commit to the architecture until you’ve built the simple thing and learned from it. Don’t pick the database until you know the access patterns. Don’t choose the framework until you’ve written the first feature without one. Every premature architectural decision is a premature abstraction — a commitment made with maximum ignorance and minimum reversibility.
The Squirrel decides immediately. The Squirrel has already chosen the database, the framework, the messaging system, and the deployment topology before the requirements document has been read. The Squirrel has read the requirements document. The Squirrel read it in eleven seconds. The Squirrel is wrong about the requirements, but the architecture is already committed, and the Squirrel will make the requirements fit the architecture rather than the other way around.
THE DECISION MADE TOO EARLY
IS A WALL BUILT BEFORE
THE ROOM IS MEASUREDTHE DECISION MADE TOO LATE
IS A DOOR INSTALLED
AFTER THE BUILDING HAS BURNEDTHE DECISION MADE
AT THE LAST RESPONSIBLE MOMENT
IS THE DOOR INSTALLED
WHILE THE ROOM STILL NEEDS ONE— The Lizard
Principle 5: Empower the Team — The Andon Cord, Revisited
At Toyota, any worker on the production line could pull the andon cord and stop the entire line. Any worker. Not the manager. Not the quality inspector. Not the Senior Vice President of Line-Stopping Strategy. The worker who saw the defect had the authority to halt production, because the worker who sees the defect is the one with the information, and routing that information through a management hierarchy before acting on it is itself a waste — muda of the purest kind.
The Poppendiecks translated this directly: the people doing the work make the decisions about the work.
In software, this means giving developers deploy access instead of routing every deployment through a change advisory board that meets biweekly and has never once prevented an outage but has definitely caused several by delaying critical fixes past the point of relevance. It means trusting the team to decide the technical approach instead of having an architecture review board approve technology choices made by people who last wrote code during the Clinton administration.
The Lean article covers the andon cord in depth. What matters here is the Poppendiecks’ insight that the cord is not a mechanism — it is a permission. Western manufacturers installed cords and nobody pulled them. The cord without the culture is furniture. The culture without the cord finds another way. Toyota had both. Most enterprises have neither, but they do have a Confluence page about psychological safety.
Principle 7: Optimize the Whole — Why Microservices Fail
Principle 7 is the systems thinking principle, and it is the one that explains the most expensive failures in modern software.
Don’t sub-optimize parts at the expense of the whole system. Each team optimizing their own service is local optimization. Each service with excellent response times inside a system with terrible end-to-end latency is a collection of fast parts producing a slow product. The customer does not experience your microservice. The customer experiences the sixty-seven network hops between your microservices.
This is why Microservices often fail. Not because microservices are wrong — but because each team optimizes their service while nobody optimizes the system. The service mesh adds 400 milliseconds of latency. The distributed tracing tool takes longer to query than the original monolith took to respond. The Grafana dashboard looks like a Christmas tree, and nobody is responsible for the tree — only for their individual ornament.
The Poppendiecks would recognize this instantly. It is the software equivalent of optimizing individual workstations on an assembly line while ignoring the flow between them — the exact failure mode that Ohno spent three decades eliminating at Toyota.
The Squirrel optimizes its module. The Squirrel’s module is fast, clean, well-tested, and beautifully abstracted. The Squirrel’s module is also responsible for 73% of the system’s total latency, because the Squirrel’s beautiful abstraction makes fourteen network calls that a monolith would have made as function calls. The Squirrel does not see this, because the Squirrel does not look at the whole. The Squirrel looks at its module. Its module is excellent. The system is on fire.
The Complementary Pair: Pike and Poppendieck
Pike’s Rules tell you how to write code. Poppendieck’s Principles tell you how to organize the work of writing code. They operate at different scales and arrive at the same conclusions.
Pike says: don’t optimize until you’ve measured. Poppendieck says: eliminate waste — and optimizing the wrong thing is waste.
Pike says: use simple algorithms and simple data structures. Poppendieck says: build integrity in — and simplicity is integrity.
Pike says: data dominates. Poppendieck says: amplify learning — and the data is the teacher.
Pike says: n is usually small. Poppendieck says: deliver fast — and you find out n is small much sooner when you ship.
One is the microscope. The other is the telescope. Both point at the same truth: simplicity, feedback, and the radical act of trusting the people who do the work.
The Squirrel Audit
The Caffeinated Squirrel’s relationship with Poppendieck’s Principles has been documented extensively by field researchers and at least two therapists:
-
Principle 1 (Eliminate Waste): The Squirrel is waste. Not maliciously — enthusiastically. Every unnecessary feature, every speculative abstraction, every “what if we need this later” is the Squirrel pulling the lever on the muda machine. The Squirrel calls this “future-proofing.” Poppendieck calls it “overproduction.” Ohno would have called it muda and stopped the line.
-
Principle 3 (Decide as Late as Possible): The Squirrel decides as early as possible. The Squirrel decided the architecture before the meeting started. The Squirrel decided the technology stack on the walk to the whiteboard. The Squirrel has insufficient information and maximum confidence, which is the precise inverse of the last responsible moment.
-
Principle 7 (Optimize the Whole): The Squirrel optimizes its part. The Squirrel’s part is magnificent. The system is a distributed monument to local optimization, and the end-to-end latency could be measured with a calendar.
The Lizard, by contrast, embodies all seven principles without having read any of them:
- Eliminates waste by not producing it in the first place.
- Amplifies learning by sitting still and observing until the pattern is clear.
- Decides at the last responsible moment, which it calls “not yet.”
- Delivers fast when it delivers at all — the Lizard’s tongue is the fastest deploy pipeline in nature.
- Empowers the team by not being the team’s bottleneck.
- Builds integrity in by never compromising on correctness.
- Optimizes the whole by refusing to care about any individual part more than the system.
The SAFe Divergence
It is worth noting what happened when the enterprise got hold of Lean software principles. The Poppendiecks wrote seven principles that fit on a napkin. SAFe took those principles, added a portfolio layer, a program layer, a team layer, ten essential elements, a 47-page certification guide, a revenue model, and the Scaled Agile Framework Big Picture — a diagram so complex that it is itself a violation of Principle 1 (waste), Principle 3 (premature commitment to a framework), and Principle 7 (sub-optimizing the parts of Agile at the expense of actually being agile).
The Poppendiecks translated Lean into seven principles. SAFe translated seven principles into seven hundred pages. This is known in Lean terminology as muda of the second kind — the waste of processing that adds no value — and it is the most expensive irony in the history of software methodology.
Measured Characteristics
Principles in the Poppendieck model: 7
Pages needed to explain them: ~200 (the book is concise)
Pages in the SAFe certification guide: 47 (minimum)
Toyota workers who could stop the line: any
Enterprise developers who can deploy to production: the ones with the VP's calendar invite
Wastes identified by Poppendieck: 7
Wastes generated by ignoring Poppendieck: all 7, simultaneously
Years since publication: 23
Industry adoption of the principles: the vocabulary, not the discipline
Times the Squirrel has violated Principle 1 today: ongoing
Times the Lizard has embodied Principle 3 today: all of them (it hasn't moved)
Decisions made at the last responsible moment: few (too late is common, too early is epidemic)
Books that translated Toyota correctly: 2 (the Poppendiecks')
Books that translated Toyota into certifications: hundreds
Principles Pike and Poppendieck share: all of them, at different scales
See Also
- Lean — The source material. Ohno, Toyota, the seven wastes, the andon cord.
- YAGNI — Principle 1’s most famous child.
- Gall’s Law — Principle 3 in systems-theoretic form.
- Patience — Principle 3 as a virtue, not a business practice.
- Pike’s Rules — The complementary set: how to write the code, not how to organize the work.
- Agile — The movement that adopted Lean’s vocabulary and misplaced its discipline.
- SAFe — What happens when seven principles become seven hundred pages.
- Kanban — Principle 4 (deliver fast) made visible with cards and WIP limits.
- The Lizard — Embodies all seven principles. Has read none of them.
- The Caffeinated Squirrel — Violates principles 1, 3, and 7. Simultaneously. With enthusiasm.
