You can never be too rich or too lean.

–Dean Leffingwell

Lean Abstract

The Scaled Agile Framework is based on a number of trends in modern software engineering, including

Lean thinking
Product development flow
Agile development

But in the broadest sense, it is to Lean that we must look for the guiding principles we need to scale Lean|Agile development across the entire enterprise. Our Lean icon represents our Software House of Lean, our derivation from a traditional representation. The SAFe House of Lean provides five key constructs:

The Goal (Roof): Sustainably shortest lead time. Best quality and value to customers, our people and society.
Left Pillar: Respect for People
Right Pillar: Kaizen (Continuous Improvement)
The Foundation: Management: Lean Thinking Manager-Teachers
Contents: Principles of Product Development Flow

This latter set, the Principles of Product Development Flow, best reflects many of the underlying principles behind the practices described in the Scaled Agile Framework, and we’ll describe those further shortly.

Details

The Software House of Lean

While initially derived from lean manufacturing, the principles and practices of Lean thinking as applied to software and product development are deep and extensive. Larman and Vodde [1] have described a framework for Lean thinking which puts many of the core principles and practices into a manageable software context. In so doing, they introduced a “house of Lean thinking for software” graphic, inspired by earlier houses of Lean from Toyota and others. Our variant for the Framework’s “Software House of Lean” is illustrated in Figure 1 below.

Figure 1. The Software House of Lean

The Goal: Sustainably Shortest Lead Time. Best Quality and Value to Customers, Our People, and Society.

The goal of Lean is unarguable – to sustainably deliver the maximum amount of value to the customer in the shortest possible lead time, while providing the highest possible value and quality to our customers, our people, and society as a whole. To help achieve this, Lean focuses on achieving continuous flow, identifying delays and non-value added activities, and constantly reducing them. As others put it:

“All we are doing is looking at the timeline, from the moment the customer gives us an order to the point where we collect the cash. And we are reducing the timeline by reducing the non-value added wastes.” — Taiichi Ohno

“Focus on the baton, not the runners”. – Larman and Vodde [1]

“Create continuous process flow to bring problems to the surface“. – Liker [2]

So in our work, we are reminded to:

To improve our understanding of our process, we focus on customer requirements, code, and tests as they move through the system, rather than on the people and organizations who manage them
Search for, and actively minimize delays, handoffs and other non-value added activities
Implement continuous flow for maximum throughput and to surface problems that present us from further accelerating value delivery

Pillar 1 – Respect for People

While it is fair to “focus on the baton and the process” we must constantly be aware that it is our people who actually do all the value added work, and respect for people is a comforting and fundamental principle of Lean and Agile (Manifesto: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.)

In addition, people are empowered in Lean to evolve their own practices and improvements. Management challenges people to change and may even ask what to improve, but the teams and individuals learn problem solving and reflection skills, and make the appropriate improvements.

Pillar 2 – Kaizen (Continuous Improvement)

This leads to the second pillar of Lean, “kaizen” (roughly translated: we can do better). With kaizen, we are “guided to become a learning organization through relentless reflection and continuous improvement”.

Use continuous improvement to determine the root cause of inefficiencies and apply effective countermeasures
Reflect at key milestones and after you finish a project to openly identify all the shortcomings of the project

For more on this critical element of the Framework, see the left most column in Figure 1 above, and also Inspect and Adapt and Retrospective.

Foundation – Lean Thinking Manager-Teachers

The foundation of Lean thinking is management support. In fact, “support” is an inadequate word. Here, our philosophy is simple: the ultimate responsibility for adoption and success lies with the enterprises existing managers, leaders and executives. Such a responsibility cannot be delegated to the agile champions, Agile Working Group, development teams, process teams, outside consultants, or any other party. To achieve this, our leaders must be trained in these new and innovative ways of thinking and operating. These “Lean Thinking Manager-Teachers” exhibit the following characteristics:

They are trained in the practices, roles, activities and artifacts of the Scaled Agile Framework
They understand Lean and Agile principles, base their day-to-day decisions on this long term philosophy, and understand and teach these behaviors
They develop people. Their people develop solutions.
They are trained in the practices and tools of continuous improvement and teach employees problem solving and corrective action skills
They are “hands on” in the new process adoption, eliminate impediments, and facilitate organizational change management
They take personal responsibility for Lean|Agile success

Here, Lean deviates from much of our experience with Agile, which was often introduced solely as a team-based process that even tends to exclude management. That does not scale! Here we have a key differentiator between traditional Agile and one of the drivers for the SAFe Lean|Agile framework:

In traditional Agile, it has been our expectation that management supports us, and helps eliminates impediments as they arise. In Lean|Agile, the expectation is that management leads us, is competent in the basic practices, proactively eliminates impediments, and takes an active role in driving organizational change and continuous improvement.

Contents: Principles of Product Development Flow

In the center of the Software House of Lean are the various principles and practices teams use to develop and deliver software to their end users. In SAFe, we rely primarily on eight major Themes (Principles) of Product Development Flow (Reinertsen [3]). These are:

Take an economic view. Establish the decision framework for your specific context, at the team, program, or enterprise level. Understand the full value chain. Do not consider money already spent. Sequence high risk, low cost activities first (WSJF). If you only quantify one thing, quantify the cost of delay.
Actively manage queues. Long queues are universally bad, as they create longer cycle times, increased risk, lower quality, and decreased motivation. Actively manage queue lengths (see (Program Backlog) and provide predictable wait times by applying Little’s Law [4]. Operate at below peak levels of utilization to increase throughput and responsiveness to change.
Understand and exploit variability. In manufacturing, variability is minimized to create predictable results, efficiency and quality. In software development, variability is inherent. Instead of eliminating variability, we must design systems that expect and address variability and even exploit it when appropriate.
Reduce batch sizes. Large batch sizes create unnecessary variability and cause severe delays in delivery and quality. The most important batch is the transport (handoff) batch between teams and between roles within a team (cross functional Agile Teams address this directly). Optimize proximity (co-location) to enable small batch sizes. Good infrastructure (test automation, continuous integration…) and loose architectural coupling enable delivery of software in small increments [batches].
Apply WIP constraints. Control queue length by applying constraints to work in process (short iterations). Limiting work in process helps force the input rate to match available capacity (architecture and Portfolio Kanbans). Timebox deliveries to help prevent uncontrolled expansion of work (PSI). Constrain global WIP pools by constraining local WIP pools (Iteration, PSI, Porfolio) . Make WIP continuously visible (Big Visible Information Radiators)
Control flow under uncertainty – cadence and synchronization. Cadence is a predictable rhythm that helps us transform unpredictable events into predictable events. Cadence makes waiting times predictable, lowers transaction costs, and increases dependability and reliability of product development. Periodic resynchronization allows us to limit variance and misalignment to a single time interval. Regular, system-wide integration provides high fidelity system tests and objective assessment of project status. Regular synchronization facilitates cross-functional tradeoffs and high bandwidth information transfer (Release Planning)
Get fast feedback. Software development cannot innovate without taking risks and we need fast feedback to take fast action (Agile Testing and Product Owner review, short iterations, short release time frames, minimal delays between code and test). Small batch sizes (increments) promote fast feedback, but require increased investment in CI and Test Automation.
Decentralize control. Delays in decision making slow feedback and simultaneously decrease the fidelity of the decision, due to the decay or evolution of facts that occur during the waiting time. Teams must be empowered to make decisions, and act quickly and efficiently. (Sprint Planning, Daily standup, release planning)

These eight themes provide a proven economic, quantitative, and mathematical basis for the Framework, so as we’ve already noted above, they are instantiated in various practices throughout.

Learn More

[1] Larman, Craig, and Bas Vodde. Scaling Lean & Agile Development. Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley, 2008.

[2] Liker, Jeffrey. The Toyota Way. 14 Management Principles from the Worlds Greatest Manufacturer. McGraw-Hill. 2004.

[3] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[4] Little’s Law tells us that the average waiting time in a queue is equal to the average length of the queue divided by the average processing time. Long queues and slow cycle times beget long waits.

[5] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last modified 30 April, 2013