Lean and Agile: Ancestors and Cousins

The Agile Manifesto was written in 2001. Toyota's production system began evolving in the 1940s. Lean thinking predates agile by more than half a century.

This matters because Agile practices often make sense only in light of Lean principles. Why do we favor "working software over comprehensive documentation"? Because documentation before coding is inventory—a form of waste. Why do we want "responding to change over following a plan"? Because long-term plans are speculation, and speculation produces waste when reality differs.

Many agile struggles come from teams adopting practices without understanding the underlying principles. They do daily standups because Scrum says to, not because they understand how it reduces coordination waste. They time-box sprints because that's the framework, not because they understand how small batches reduce risk.

When you understand Lean, Agile practices become obvious. When you don't, they seem like arbitrary rituals.

Scrum adopted several Lean concepts:

• Time-boxing as a batch size constraint
• Cross-functional teams to reduce handoffs
• Retrospectives for continuous improvement
• Self-organization as respect for people
• Working software each sprint (JIT delivery)

Extreme Programming (XP) is even more explicitly Lean:

• Pair programming reduces defects (build quality in)
• Continuous integration prevents inventory (small batches)
• Test-driven development catches bugs early (Jidoka)
• Simple design avoids waste (YAGNI)
• Sustainable pace respects people

Kanban is the most directly Lean-derived method. David Anderson explicitly adapted TPS concepts: pull systems, WIP limits, flow visualization, continuous improvement. If Scrum borrowed Lean's philosophy, Kanban borrowed its mechanisms.

None of these methods require you to understand Lean to use them. But understanding Lean helps you:

• Know when to break the rules
• Adapt practices to your context
• Diagnose why things aren't working
• Combine practices coherently

While Lean provides the foundation, Agile added important elements for knowledge work:

Embrace uncertainty: Manufacturing Lean optimized known processes. Software development faces fundamental uncertainty—we often don't know what to build or how to build it until we try. Agile explicitly builds in mechanisms for discovery: iterations, user feedback, pivots.

Timeboxes: TPS didn't need sprints—production was continuous. Agile introduced timeboxes as a forcing function for software teams unused to continuous flow. The timebox creates rhythm, limits scope creep, and forces regular delivery.

Ceremonies: Retrospectives, standups, reviews—these are mechanisms for the feedback loops Lean requires, tailored to knowledge work teams. They're not unique to Agile (Toyota had similar practices), but Agile codified them for software.

The human element: While Lean's "Respect for People" pillar is profound, Agile made it more explicit for knowledge work. The Manifesto's "individuals and interactions over processes and tools" and XP's "sustainable pace" emphasize that knowledge work requires intrinsic motivation, not just process efficiency.

Neither Lean nor Agile is complete alone. Lean provides principles and theory. Agile provides specific practices for software. The best teams draw from both.