Leading Lean Software Development: Results Are Not the Point (2009) is the third and culminating book by mary-poppendieck and tom-poppendieck, published by addison-wesley. It completes the trilogy that lean-software-development-agile-toolkit-2003 and implementing-lean-software-development-2006 began — moving from principles to implementation to the organizational and leadership conditions that make lean transformation possible and durable.
The Central Thesis
The subtitle "Results Are Not the Point" is the Poppendiecks' most provocative and intellectually mature claim. It encapsulates the learning-not-results thesis: that in software development, learning is the primary value stream, and results — features shipped, velocity achieved, commitments met — are lagging indicators of the learning capacity of the organization. Managing to results is managing to the wrong target. It produces local optimization, gaming of metrics, and the suppression of the feedback that enables improvement.
This thesis connects the Poppendiecks directly to w-edwards-deming's warning against managing to short-term numerical goals, and foreshadows what would later be articulated by lean startup thinkers in the validated learning framework. But the Poppendiecks arrived at it through a different route: the observation that software, unlike manufactured goods, is primarily a knowledge-creation activity. The value created is understanding — of the problem, of the customer's need, of the solution space. Results without learning are a sign that the team is executing known solutions to known problems, which is precisely not what software development is for.
Leadership Behaviors
Mary had previewed these themes at the Agile 2007 keynote and in the 2008 leadership paper. The book organized its argument around leadership frames — the mental models and behavioral patterns that enable or prevent lean transformation. The Poppendiecks identified several dominant failure modes in organizational leadership:
Managing to output over managing to learning. Organizations that track velocity, story points, and feature counts while ignoring cycle time, defect escape rates, and feedback loop length are optimizing the wrong level.
Local optimization over optimize-the-whole. This is the lean principle most consistently violated in practice. Functional managers optimizing their own teams' metrics create handoff delays, inventory accumulation, and queues that degrade system-level performance — even as each component looks locally efficient.
Pushing work over pulling. pull-systems-in-software require trusting the team to pull work when ready, which requires trusting that the team's judgment about capacity is better than a manager's schedule. The behavioral change required is profound, not just procedural.
Systems Thinking at Scale
The 2009 book addressed what the earlier volumes had largely bracketed: how do lean principles apply to large organizations with multiple teams, complex dependencies, and entrenched processes? The Poppendiecks engaged with Donella Meadows' systems thinking framework and with the organizational learning tradition (Senge, Argyris) to argue that lean transformation is fundamentally a learning challenge, not a process-improvement challenge.
The key systems insight is that organizations have feedback loops that either accelerate or dampen learning. Bureaucratic approval processes, large batch releases, and annual performance reviews are all delay mechanisms that stretch the feedback loops that learning depends on. amplify-learning at the organizational level requires identifying and compressing these delays — not just at the team level (which implementing-lean-software-development-2006 addressed) but at the level of organizational structure, governance, and management practice.
empower-the-team at Scale
The empower-the-team principle, introduced in lean-software-development-agile-toolkit-2003, receives its fullest treatment in the 2009 book. The Poppendiecks examined what empowerment actually requires beyond the platitude: teams need clear purpose, relevant information, appropriate authority, and the skills to exercise judgment. Most organizational attempts at empowerment fail because one or more of these prerequisites is absent — teams are given autonomy over methods but not over goals, or given goals without information, or given authority without capability.
This analysis drew on Toyota's operational philosophy — specifically the distinction between hoshin kanri (policy deployment aligning organizational direction with team-level work) and the floor-level decision authority given to Toyota workers who could stop the production line. The Poppendiecks showed that both levels are necessary: empowerment without alignment produces fragmentation; alignment without empowerment produces compliance theater.
Position in the Trilogy and the Broader Lineage
Leading Lean Software Development is where the Poppendiecks' intellectual project reaches its most abstract and most generalizable form. The first book gave practitioners a framework; the second gave them tools; the third gave them a theory of organizational change. Together, the three books constitute one of the most complete arguments in the Agile and lean software literature for why the dominant assumptions of software management — control, prediction, output — are wrong, and what should replace them.
The book's themes prefigure much of what gene-kim and colleagues would develop in the DevOps movement, and what the continuous delivery community (Jez Humble, Dave Farley) would articulate as the relationship between deployment pipeline design and organizational learning capacity. The Poppendiecks recognized that the bottleneck to lean software is not usually technical — it is the leadership mindset and organizational structures that resist the feedback and learning that lean requires.