Lean Software Development: 7 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 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 “Lean Software Development: An Agile Toolkit” (2003), and refined the wording of their seven principles in “Implementing Lean Software Development” (2006). Those principles are still the best diagnostic framework I know for identifying why software teams struggle. Let me walk through them honestly.

What Are the Seven Principles of Lean Software Development?

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. You will often see a Standish Group figure quoted here, that 64% of features are rarely or never used, but the evidence behind it is weak. You don’t need the number to see the problem: the Agile principles call simplicity, “the art of maximizing the amount of work not done,” essential for a reason.

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, which Taiichi Ohno describes in “Toyota Production System” (1988): 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. Knowledge creation 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

Speed here is a mechanism for fast feedback, and velocity for its own sake misses the point. 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, instead of being 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? DORA measures a close cousin of this as lead time for changes. 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 came mainly from people rather than technology. 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 history of Agile traces how these ideas travelled from Toyota into software.)

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, with nothing deployed or validated; compare a real Definition of Done) 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.

How Do You Start With Lean Without a Full Transformation?

If you can’t do all of Lean at once (you can’t), start with the one practice that will make the biggest difference in your specific situation:

• If your team has a lot of WIP and half-finished features: set strict WIP limits, stop starting and start finishing
• If quality issues are slowing everything down: invest in automated testing infrastructure
• If decisions are being made too early and causing rework: implement deliberate decision points with explicit conditions for deciding
• If features are reaching users slowly: map your deployment pipeline and find where work waits

Lean Tells You Where to Look

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.