The Agile Handbook

Lean Software Development: Seven Principles, Applied Honestly

Last updated on

Lean Software Development: Seven Principles, Applied Honestly

Most Agile Teams Are Doing Lean Badly Without Knowing It

“Eliminate waste” sounds obvious. Of course you want to eliminate waste. But here’s the thing: most development teams I’ve observed are generating enormous amounts of waste and calling it work. They’re not being lazy — they’re often working very hard. The waste is structural.

Mary and Tom Poppendieck translated Lean Manufacturing principles into software development terms in 2003, and their seven principles are still the best diagnostic framework I know for identifying why software teams struggle. Let me walk through them honestly.

The Seven Principles: Where Teams Actually Go Wrong

Eliminate Waste

The Poppendiecks identified seven categories of waste in software development. The two that destroy teams most consistently:

Partially done work — code that’s written but not integrated, features that are 90% complete but not shipped, designs that are approved but not implemented. Partially done work takes up mental space, creates merge conflicts, gets outdated, and contributes nothing to users. A story that’s 90% done is worth zero until it ships.

Extra features — building things that nobody asked for, adding configuration options “just in case,” implementing the “complete” version of a feature when a simpler version would do. Industry data suggests between 20-64% of features in typical software are rarely or never used. That’s most of your team’s effort going toward things that don’t help anyone.

The practical question Lean asks about any work item: does this add value for the customer? If the honest answer is “not directly, but…” — that’s waste. Some waste is unavoidable (audits, compliance, infrastructure). Minimizing it requires being honest about what “unavoidable” actually means versus what’s habit or political cover.

Build Quality In

Lean’s position on quality is clear and counterintuitive to traditional project management: quality cannot be inspected in after the fact. It must be built in continuously.

This is why Toyota built the Andon cord — any worker could stop the production line when they spotted a defect. They stopped production to prevent defects from propagating. This is expensive in the short term and dramatically cheaper in the long term.

The software equivalent is automated testing, continuous integration, and a culture where developers can and do stop work to fix quality issues as they’re found rather than logging them for later. “We’ll fix it in the bug-fix sprint” is the antipattern — it’s a commitment to propagating defects forward in time.

Teams that have two-week sprint cycles and a separate quarterly “hardening sprint” are doing precisely the opposite of building quality in. They’re scheduling debt repayment instead of preventing debt creation.

Create Knowledge

This principle is the most undervalued and the most frequently reduced to “write documentation.” It’s not about documentation. It’s about creating conditions where teams learn continuously and that learning propagates through the organization.

Retrospectives, if done well, are knowledge creation. Pair programming is knowledge creation. Post-incident reviews are knowledge creation. But the knowledge only has value if it changes behavior — if learnings from one project actually inform the next project, if failure modes discovered in a retrospective lead to changed practices.

Most teams do retrospectives and then repeat the same mistakes next quarter. That’s information gathering, not knowledge creation. Knowledge requires a feedback loop that changes something.

Defer Commitment

This is Lean’s most sophisticated principle and the one most at odds with organizational governance expectations. The idea: make decisions at the “last responsible moment” — as late as possible without foreclosing options.

In practice: don’t choose your database technology before you understand your query patterns. Don’t design your API contract before you understand how clients will actually use it. Don’t hire for a skill before you know exactly what you’re building.

Organizations that require detailed upfront specifications — and many do, for entirely understandable political reasons — are structurally opposed to this principle. If you must commit to specifics early, at least identify which commitments are decisions and which are assumptions. Revisit assumptions as information arrives.

Deliver Fast

Not velocity for its own sake. Fast delivery as a mechanism for fast feedback. A feature that takes six months to reach users is one that you’ll be wrong about for six months before you find out.

The target for most product development should be continuous delivery — features reaching users as soon as they’re ready, not batched into quarterly releases. This requires both technical capability (deployment automation, feature flags) and organizational will (releasing before marketing campaigns are ready, accepting partial features as viable).

The question to ask: what is the average time between a developer merging code and a user being able to use the feature? If that number is more than two weeks, you have a delivery bottleneck that is masking feedback that could improve your product.

Respect People

Lean’s respect principle goes well beyond being polite. It means treating workers as intelligent professionals whose expertise is valuable, whose observations about process problems are accurate, and whose working conditions enable or constrain their performance.

The Toyota Production System’s famous quality improvements were not primarily technology-driven. They were driven by creating conditions where assembly line workers could and did stop the line to prevent defects, where their ideas about improvement were solicited and implemented, and where solving problems was considered more important than maintaining schedule.

The software equivalent: teams that can stop work to address a critical technical debt issue without asking permission. Teams whose observations about process problems are acted on rather than acknowledged and filed. Teams with enough psychological safety to say “this approach is wrong” without career risk.

Optimize the Whole

The most commonly violated Lean principle in software organizations. Instead of optimizing the whole system, teams optimize locally — developers measure velocity, ops teams measure uptime, business stakeholders measure feature count — and then wonder why the overall system underperforms.

Local optimization can harm global performance. A development team that maximizes story point velocity by rushing features to “Done” — meaning finished development, not deployed and validated — may be creating deployment bottlenecks and quality issues that reduce the overall throughput of the system.

The right unit of optimization is the end-to-end value stream: from user need to working software in production. Measure that, manage that, improve that.

Starting With Lean Without a Full Transformation

If you can’t do all of Lean at once (you can’t), start with one practice that will have the most leverage for your specific situation:

Lean’s value is in its diagnostic power. The seven principles tell you what types of waste to look for. The specific countermeasure depends on what you actually find.

The honest promise of Lean: if you’re willing to look at your process empirically and change what you find, you will find both wasted effort and blocked improvement. Fixing them is hard organizational work, but the principles tell you where to look.