The SAFe Way to Lean Software Development

Colin O’Neill, Gillian Clark, and Gareth Evans


Lean Thinking makes a significant impact on organizations that are keen to stay competitive in a rapidly changing world. Because software is ubiquitous in most modern products and services, scalable agile software development techniques based on Lean principles are creating successful outcomes for numerous government and industry organizations around the globe.

The Scaled Agile Framework® (SAFe)[1] is a proven, publicly available framework for applying Lean-Agile principles and practices at enterprise scale ( SAFe, created by Dean Leffingwell, synchronizes the alignment, collaboration, and delivery of large numbers of agile teams across an enterprise and employs key Lean principles to underpin its constructs. SAFe is fundamentally based on five Lean practices as represented in the metaphorical House of Lean, located in the upper left corner of the SAFe Big Picture (depicted below). The purpose of this article is to illustrate how Lean principles buttress the constructs of the Scaled Agile Framework in both theory and practice. The following sections provide insight into how each of these Lean principles are intrinsically embodied in SAFe.



The Goal: Value

The primary goal of a Lean enterprise is to deliver value in return for revenue, brand recognition, competitive advantage, and customer, user, and employee welfare. More importantly, a Lean enterprise delivers value in the sustainably shortest lead time, while simultaneously providing “the best quality and value to people and society.” SAFe inherently supports enterprise Value Streams which document how value flows through an organization. Value Streams represent all the activities that contribute to value delivered to a customer from “concept to cash.” Agile programs, also known as Agile Release Trains (ARTs), are the regular, predictable value delivery mechanisms that realize this value via collaborative program and team objectives.


Foundation: Leadership

Effective managers must be trained in the principles of Lean Thinking so they can base their decisions on sound, long-term values and principles. In SAFe, Lean Thinking Manager-Teachers (a term derived from Eiji Toyoda’s “Toyota Way”[2]) take responsibility for enterprise success—they also understand and teach Lean-Agile behaviors to their people. Additionally, Business Owners are actively engaged in software product development and take responsibility for the quality and fitness of the systems that support their lines of business. Managers, in turn, primarily develop people, who ultimately create and deliver solutions. Specifically, Product Managers, Product Owners, and Scrum Masters operate as servant-leaders and empower their teams to deliver value in the fulfillment of business objectives.


Respect for People

An important aspect of Lean Thinking is the empowerment of teams to continuously improve the way they work. Knowledge workers (defined by Peter Drucker[3] as those who know more about their work than their bosses do) are inherently motivated to solve problems and create quality solutions when empowered to do so. Therefore, management is tasked with building employee and business partnerships based on transparency, trust, and mutual respect at all levels of the organization. This includes understanding who our customers are at each stage of product development and treating them with respect, as well as providing Agile teams with appropriate problem-solving tools and the authority to use them.



Kaizen is a Japanese word that translates as “change to become good.” Taken more broadly, it is a Lean enterprise value that represents driven, relentless reflection and continuous improvement. Recognizing that business survival often requires operating under a “constant sense of danger” from competitors and market forces, organizations make small, steady improvements to effect significant, lasting change over time.

Product Development Flow

Don Reinertsen’s 2009 seminal work The Principles of Product Development Flow[4] created a powerful mental model that SAFe uses to apply lean flow principles to software development. His eight principles of product development flow are:

  1. Take an economic view
  2. Actively manage queues
  3. Understand and exploit variability
  4. Reduce batch sizes
  5. Apply work in process (WIP) constraints
  6. Control flow under uncertainty through cadence and synchronization
  7. Get feedback as fast as possible
  8. Decentralize control

Since SAFe is based on continuous flow of delivered value within Value Streams via Agile Release Trains, mapping each of Reinertsen’s principles to the Big Picture is fundamental to understanding the full power of the Scaled Agile Framework, as seen in the sections below.


The purpose of software development is to create solutions that help people and deliver economic benefit to an organization. The focus of Reinertsen, and SAFe, is that all software development activities should be viewed through a fiduciary lens to understand the economics of the business, and analyze and reduce delays in value delivery. Software developers, testers, and others should be trained to consider their daily duties in economic terms. As a complete framework, including empowered decision-making authority at Portfolio, Program, and Team levels, SAFe provides a number of concepts that are designed to maximize economic performance of the enterprise. Some specific examples include:

  • The highest level of economic leverage begins with the Portfolio Epic Kanban system. Here, strategic investment themes (i.e., ART budgets) and lightweight business cases are used to make economic decisions and impacts visible at the enterprise level.
  • Weighted Shortest Job First (WSJF)—this lean economic prioritization tool focuses on the cost of delay (CoD) and remaining job size to determine the relative value of a set of features. WSJF is a key concept to prioritizing the flow of work within a 2-3 month timebox.
  • Lean metrics provide a holistic view of economic value that illuminates the lost opportunity cost of each delay. While it can be difficult to measure economic value directly, Lean proxy variables replace the traditional focus of human resource utilization by measuring cycle times, throughput, and delays that have the greatest economic impact.


Little’s Law tells us that the more items we have queued in a system, the longer the average time each item will take to travel through the system. Therefore, the longer the queue, the longer our customers must wait for new value. Managing queues is, therefore, a powerful mechanism for reducing wait time since long queues result in delays, waste, unpredictable outcomes, disappointed customers, and low employee morale.


In manufacturing, variability is generally bad—products must be produced within tight tolerances to ensure quality. In technology, there are many assumptions, risks, and unknowns that ensure the inevitability of software product variability. Rather than fighting entropy (and realizing “death by business case” in search of the perfect plan), organizations use short planning cycles to adjust to continuous learning and changing business/market demands, thereby exploiting variability rather than trying to contain it. The Scaled Agile Framework accepts the fact that variability exists and attempts to leverage it wherever possible by:

  • Limiting Team, Program, and Portfolio backlogs to a finite size.
  • Frequently re-planning to adjust and adapt as the organization continuously learns about the solution it’s building.
  • Deliberately employing Spikes (research activities) that allow teams to investigate and learn how a system will perform prior to estimating a story or feature.
  • Limiting the utilization of people and teams to less than 100% so an organization can flex to variability as it happens. (NOTE: This principle is especially counterintuitive to most matrixed models which attempt to set their resources to 100% utilization to increase “apparent efficiency,” something which is contradicted in The Principles of Product Development Flow)
  • Using a Hardening|Innovation|Planning (HIP) iteration to promote innovation events that allow teams the freedom to use their experience and extensive domain knowledge to discover and present innovative ideas to the business—whether it’s finding a solution to a nagging defect, or identifying a fantastic new feature.Figure4.ReduceBatchSizes

Traditionally, IT organizations have worked with large batch sizes and accepted significant transport costs (the cost of transferring work from one group to another). In SAFe, batch size reduction is achieved by having co-located, cross-functional teams that deliver small, potentially shippable increments of work. The System Team in SAFe also facilitates the reduction of transport batch size through continuous integration and validation. The collaborative DevOps approach extends the ability to reduce transport batch size by continuously reducing infrastructure and deployment costs through smaller, more frequent deliveries supported by automation. The right batch size optimally balances transaction costs (the cost to process a thing) with the holding costs associated with requirements, code, and tests becoming stale over time. At the Portfolio level, we move away from projects where we “bring people to the work”, toward epics or initiatives that “bring the work to the people” in a far more effective manner. At the Program level, we focus on features which fit into regular development cycles and can therefore be implemented by one or more teams in less than 8-12 weeks. In this way, Agile programs deliver many small increments of work, which when integrated, implement the features and epics that deliver real value to the business as early, and frequently, as possible.


Having too much work in process (WIP) results in multiplexing and context switching. The more work in process an organization has, the higher the multiplexing overhead, which can often run from 20-50%. Constraining WIP takes discipline and commitment—the easiest and most common approach is to simply balance the amount of work in process against the available capacity. Once any element of an organization reaches its capacity, they stop taking on more work. A common mantra heard in many agile organizations is “stop starting and start finishing,” which implies that a small amount of work is pulled by teams and driven to completion before starting any more work. In SAFe, WIP is constrained locally by Agile teams and made visible on BVIRs. This approach is applied at the Program and Portfolio levels in a similar manner.


SAFe uses cadence—a regular rhythm—to plan and deliver capability at iteration and PSI[5] boundaries to ensure that frequent and regular adjustments are made to the plan to help deliver predictable, valuable results. Synchronization occurs at each of the planning boundaries; for example, at iteration boundaries, all of a teams’ delivered work is synchronized, integrated, and demonstrated end-to-end as working software. Program vision, resources, and PSI objectives are synchronized at every PSI boundary. SAFe separates development cadence from release frequency (i.e., “develop on cadence; deliver on demand”) in order to provide an Agile program with the optimal heartbeat for a long-term, sustainable pace. Agile Release Trains deliver integrated, tested capability when the business is ready, which is often not on the same schedule as a Program’s regular planning and development cadence.


A key Lean principle is gathering feedback from all aspects of the software development process as frequently and as fast as possible. Feedback can be received from customers, or generated internally between teams or levels of the organization. The most valuable feedback provides new information from which we can learn. A few of examples of fast feedback are:

  • At the Team level, rapid feedback is gained through co-located, cross-functional teams sharing information and holding iteration reviews with their Product Owner every two weeks. Agile teams also use Spikes to test assumptions and validate risk. Team-level feedback is facilitated by small batch sizes, iteration retrospectives, and technical practices such as continuous integration, pair programming, and automated testing.
  • At the Program level, feedback is gained from a fortnightly System Demo and the Inspect and Adapt (I&A) Workshop, which is a program-level retrospective designed to address and remove systemic impediments. Additionally, small batch sizes in terms of the top 10 or 15 program features undertaken in an 8-12 week cycle promote faster feedback from the field.


One of the well-known strengths of Scrum is the effectiveness of self-organizing, self-managing teams. In Scrum, teams are empowered to achieve iteration goals using their domain knowledge and expertise to decide the best way to implement a solution. Empowering Agile teams and programs to make fast, local decisions at the last responsible moment is the duty of servant-leaders and Lean Thinking Manager-Teachers. Pushing decisions closer to the code face promotes local autonomy and is key to successful Agile organizations.


Lean Thinking is rapidly becoming a de-facto organizational transformation improvement standard. Applying Lean principles to software development organizations is facilitated by the adoption of the Scaled Agile Framework. Lean principles provide the foundation for successful SAFe enterprise transformations, and they explain why SAFe practices work. The Lean principles of SAFe, whilst having roots in Lean manufacturing, recognize the differences inherent in knowledge work within product development organizations. These principles represents a paradigm shift away from economies of scale to economies of flow where organizations are more concerned with the regular delivery of value than focusing on milestone gates or utilization rates of people in the system. The Framework provides a structure for each level of an organization, and each SAFe practice remains consistent with underlying Lean principles.

About the Authors

Colin O’Neill is the President of Asia Pacific Operations and co-founder of Scaled Agile, Inc. For over 27 years he has been serving technology-based clients in government and industry worldwide. Colin is a principal contributor to the Scaled Agile Framework and a frequent conference speaker on Lean-Agile topics.

Gillian Clark leads Innovation Delivery at Assurity Consulting, New Zealand. With over 20 years’ experience in IT, from project and program management to CIO. Gillian consults for many clients from financial institutions to government agencies and is a contributor to the Scaled Agile Framework, a popular speaker at various agile events and a founding member of the Agile Professional Network.

Gareth Evans is a Principal Consultant at Assurity Consulting in New Zealand. He has over 16 years of experience in the software industry, over 10 of which were in London working in banking and media. Gareth consults for many clients from financial institutions to government agencies; he is a contributor to the Scaled Agile Framework and a frequent Lean-Agile conference speaker both internationally and within New Zealand.

[1] Scaled Agile Framework and SAFe are trademarks of Leffingwell, LLC.

[2] Jeffrey Liker, The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer. McGraw Hill, 2004.

[3] Peter Drucker, Landmarks of Tomorrow. Harper & Brothers, 1959.

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

[5] PSI = Potentially Shippable Increment.