5. SAFe Principles
The impression that “our problems are different” is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the quality of product and service are universal in nature.
—W. Edwards Deming
Principle #1: Take an Economic View
Principle #2: Apply Systems Thinking
Principle #3: Assume Variability; Preserve Options
Principle #4: Build Incrementally with Fast, Integrated Learning Cycles
Principle #5: Base Milestones on Objective Evaluation of Working Systems
Principle #6: Visualize and Limit WIP, Reduce Batch Sizes, and Manage Queue Lengths
Principle #7: Apply Cadence; Synchronize with Cross-Domain Planning
Principle #8: Unlock the Intrinsic Motivation of Knowledge Workers
Principle #9: Decentralize Decision-Making
Why Focus on Principles?
The Scaled Agile Framework (SAFe) is based on Lean-Agile principles—the core beliefs, truths, and economic values that drive effective roles and practices. Principles are enduring; they stand the test of time and can be applied universally, no matter what the situation. But they’re not the same as practices. A practice is a specific activity, action, or way of accomplishing something. A practice that works in one situation may not necessarily apply or work in another.
A Lean-Agile transformation will deliver substantial benefits. However, it is a significant change, and every implementation is somewhat different. Fortunately, SAFe is a scalable and configurable framework, allowing each organization to apply it to its own business model.
Therefore, before an enterprise can effectively apply SAFe practices, an understanding of the underlying principles is required. This chapter describes nine SAFe Lean-Agile principles.
Principle #1: Take an Economic View
While you may ignore economics, it won’t ignore you.
—Don Reinertsen, Principles of Product Development Flow
Achieving the goal of Lean—the sustainably shortest lead time, with best quality and value to people and society—requires a fundamental understanding of the economics of building systems. Without such an understanding, even a technically competent system may cost too much to develop, take too long to deliver, or have manufacturing or operating costs that cannot be sustained.
Leadership, management, and knowledge workers must all understand the economic impact of their decisions. Therefore, SAFe’s first Lean-Agile Principle is to take an economic view. Two primary aspects are:
• To deliver incrementally, early, and often
• To sequence jobs for maximum benefit
In addition, Reinertsen identifies a supporting set of economic principles. These are as follows:
• Do not consider money already spent.
• Understand economic trade-off parameters.
• Make economic decisions continuously.
• Use decision rules.
Each of these is discussed in this chapter.
Deliver Incrementally, Early, and Often
The Agile economic imperative and primary benefit of SAFe is that solutions are developed iteratively and incrementally. Each increment reduces risk and uncertainty and produces value. As shown in Figure 5-1, this is in stark contrast to a single-pass, phase-gate, waterfall development approach.
Each increment (the little boxes in Figure 5-1) delivers value to the customer much earlier in the development process, as shown in Figure 5-2.
Moreover, the value of each increment persists over time, and the accumulated value delivers substantial benefits even early in the solution life cycle. In contrast, all the value for waterfall delivery must wait until the end (and that’s only if it’s delivered on time!), when all the features are completed.
In addition, there is a compounding economic factor: New features or solutions delivered early to market are typically more valuable than those delivered later, as shown in Figure 5-3.
This means that a solution delivered early—even with a set of minimum viable features—provides more total economic value than a theoretically more complete product delivered later. Early and often is simply better economically. That is the Agile economic imperative.
Sequence Jobs for Maximum Benefit
Earlier, we mentioned the important role that Reinertsen’s Principles of Product Development Flow plays in providing many of the primary underpinnings for SAFe. After all, SAFe is a flow-based system, designed to provide a continuous flow of value to the customer. This is a critical difference from traditional systems development, which tends toward large, infrequent releases.
In turn, this triggers a fundamentally different requirement for prioritization of work. In a flow-based system, work must be reprioritized continuously, based upon the economic and technical facts known at that time. Understanding how to sequence jobs is critical to achieving the best economic outcomes.
Reinertsen describes an algorithm for job sequencing called Weighted Shortest Job First (WSJF). WSJF is calculated by dividing the Cost of Delay (CoD) for a job (value not achieved while waiting) by the duration of the job.
The job with the highest WSJF is the next most important job, as it delivers the most value in the least amount of time. WSJF can be applied at any level of SAFe.
For further understanding of WSJF, refer to Reinertsen’s original work1 and the SAFe article2 by that name. In the context of SAFe, we still need to establish mechanisms for determining CoD and duration so teams can calculate WSJF.
1. Donald Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Celeritas, 2009).
2. http://dev.scaledagileframework.com/wsjf/
Calculating the Cost of Delay
In SAFe, “jobs” are the epics, features, and capabilities that deliver value. SAFe describes these three primary parameters that contribute to the CoD:
• User and/or business value. This item represents the net value to the user and/or business of the particular job. Do the users prefer this over that? What is the revenue impact?
• Time criticality. This value captures the time-sensitivity of the job. Does timing of delivery matter? Is there a fixed deadline? Will the customers wait or move to another solution?
• Risk reduction and/or opportunity enablement. This value represents some of the important intangibles. What else does this do for our business? Does it reduce the risk of this or a future delivery? Will this feature open up new business opportunities?
The sum of these parameters is the total CoD for the job.
To establish the value, it isn’t necessary to attempt to establish absolute metrics for these parameters. Instead, Agile teams use relative estimating to estimate work, and this technique applies well to the CoD parameters. In other words, teams just compare jobs to each other and rank each parameter relative to other jobs.
Duration
Next, teams need to estimate job duration. That can be somewhat difficult, as at the time of prioritization, it may not be possible to know what people are available, which affects the duration of the job. Fortunately, all other things being equal, bigger jobs take longer to do, so job size is a good proxy for duration. Relative estimating can be used here, too, to quickly establish the job size. Agile teams get pretty good at estimating relative job size.
Calculate Weighted Shortest Job First
With that data, jobs can then be compared to each other via a reasonably straightforward calculation, using the worksheet illustrated in Figure 5-4.
Teams enter the job name and the individual parameters relative to other jobs and then calculate the result. The jobs with the highest WSJF are the next highest priority. This serves as a fairly straightforward, fast, and effective prioritization technique, which allows stakeholders for ARTs, value streams, or the portfolio to pick the next most important job to work on.
There are other advantages to this technique as well.
• Because of the job size denominator, WSJF favors smaller jobs. Therefore, larger jobs must be broken down into smaller ones to obtain a higher priority. That encourages incremental development.
• Since the updated job size estimates include only the work remaining, frequently reprioritizing automatically eliminates consideration of money already spent (“sunk costs,” another consideration that we will discuss in this chapter).
Supporting Economic Principles
Delivering incrementally and sequencing jobs are two essential aspects for achieving better business outcomes. However, Reinertsen describes a number of additional economic principles as well, including the following:
• Do not consider money already spent.
• Understand the economic trade-off parameters.
• Make economic choices continuously.
• Use decision rules to decentralize economic control.
Do Not Consider Money Already Spent
While it might seem obvious, it’s important to note that money already spent is a “sunk cost.” It’s gone, it isn’t coming back, and it should never enter into an economic choice about future priorities.
Managers, however, often face the pressure of continuing investment in projects, influenced by the amounts of money already spent. After all, no one wants to “lose the investment,” and/or face the political consequences of killing a project. It just looks bad, even when it’s the right thing to do. So, often cash continues to pour into projects that will not deliver intended benefits, hoping somehow that it will all work out in the end.
When deciding whether to pivot or persevere with further investment, ignore sunk cost. Instead, fully examine whether the incremental effort will justify the remaining value. After all, there may be other, potentially higher WSJF jobs, waiting to be implemented.
Understand Economic Trade-Off Parameters
Reinertsen notes that “understanding economics requires understanding of the interaction amongst multiple variables.” Figure 5-5 illustrates five parameters that can be used as an analysis tool to improve economic decision-making for developing new products and services.
1. Development expense is the cost of labor and materials required to implement a capability.
2. Cycle time measures the period from the beginning to the end of a process.
3. Product cost is the manufacturing expense and/or deployment and operational costs.
4. Value is the economic worth of the capability to the customer.
5. Risk is the uncertainty of the technical or business viability of the solution.
Sometimes the absolute value of these numbers cannot be easily determined. But most generally, this is a thinking tool, and these trade-offs do not necessarily require knowing the precise monetary value of each parameter. The following insights from our students serve as good examples of how this analysis can be applied in the real world:
• Delayed performance testing increases cycle time, increases development expense, and diminishes the value of features.
• Test automation decreases cycle time, reduces risk, and reduces overall development expense.
• Late defect fixing increases development expense and increases cycle time and risk.
Make Economic Choices Continuously
In flow-based systems, the timing and frequency of economic choices is not a one-time, up-front event. Instead, choices must be made continuously. The following are just a few examples of how this applies:
• Portfolio epics are continually re-prioritized as they go through the various steps of the kanban system.
• The program and value stream backlogs are continually refined and re-prioritized at PI boundaries.
• Set-based design keeps multiple requirements and design choices open for longer periods of time.
• System demos provide frequent integration points that inform design choices and decisions as to when to release value.
• Teams continuously prioritize their backlog of user stories, defects, spikes, and refactors.
Use Decision Rules to Decentralize Economic Control
The path to Lean success doesn’t just begin and end at the top of the organization, where a handful of people make all the decisions. Indeed, “as you move lower in a decision network, the number of small decisions being made increases in number, making it possible for the combined value of these small choices to exceed the value of the larger decisions.”3
3. http://www.decision-making-solutions.com/small-decisions.html
Decision rules establish the economic logic and reasoning behind a decision. They support decentralized, and better, decision-making. Good decision rules enable teams to make the right decisions faster, by doing the following:
• Aligning economic choices made within and across programs
• Reducing risk and enabling more decisions to be decentralized
• Reducing the effort required to make good decisions
• Providing transparency into the economic logic for decisions
Ultimately, teams execute strategy via implementing the solutions necessary to accomplish strategic intent. In so doing, they make many decisions every day. Management helps teams make better decisions by developing decision rules that help teams make better economic choices.
Principle #2: Apply Systems Thinking
A system must be managed. It will not manage itself. Left to themselves, components become selfish, independent profit centers and thus destroy the system. ... The secret is cooperation between components toward the aim of the organization.
—W. Edwards Deming
Chapter 1, “Business Need for SAFe,” briefly introduced systems thinking as one of the three foundational bodies of knowledge in SAFe. Systems thinking takes a holistic approach to solution development. It incorporates all aspects of a system and its environment into the design, development, deployment, and maintenance of the system itself.
Figure 5-6 illustrates the primary aspects of systems thinking. Understanding these aspects helps leaders and teams navigate the complexity of solution development, the organization, and the larger picture of total time to market.
SAFe provides guidance for the development and deployment of complex software and systems. SAFe calls this the solution and is the output of each value stream. Applications, satellites, medical devices, and websites are all examples of solutions. When it comes to such systems, Deming’s guidance that “a system must be managed” leads to a number of critical insights.
• The boundaries of the system, what it is, and how it interacts with the environment and systems around it must be clearly understood.
• Optimizing a component does not optimize the system. When developing systems, it’s important to assure that the components do not become selfish and hog the resources—computing power, memory, electrical power, whatever—that other elements need.
• For the system to behave well as a system, an understanding of the intended system behavior and some higher-level understanding of its architecture (how the components work together to accomplish its aims) are necessary. The intentional design of a system is fundamental to systems thinking.
• The value of a system passes through its interconnections. Those interfaces—and the dependencies they create—are critical elements to providing ultimate value. Continuous attention to those interfaces and interactions is vital.
• A system can evolve no faster than its slowest integration point. The faster the full system can be integrated and evaluated, the faster the actual knowledge of the system grows.
The second aspect to systems thinking—the people, management, and processes of the organization that builds the system—is also system. The understanding that systems must be managed applies here as well, and all of these roles apply here, too. Otherwise, the components of the organization building the system will optimize locally and become selfish, limiting the rate and quality of the overall value delivery. This leads to another set of systems thinking insights.
• Building complex systems is a social endeavor. Therefore, leaders must facilitate the creation of an environment where people can collaborate on the best way to build better systems.
• Suppliers and customers are integral to the value stream. They must be treated as partners, based on a long-term foundation of trust.
• Optimizing a component does not optimize the system here either. Locally optimizing teams or functional departments does not optimize the flow of value through the enterprise.
• Value crosses organizational boundaries. Accelerating value delivery requires eliminating functional silos and creating virtual cross-functional organizations, such as an Agile Release Train (ART).
Understand and Optimize the Full Value Stream
The entire SAFe portfolio is considered to be a collection of value streams, each of which delivers one or more solutions to the market. As illustrated in Figure 5-7, each development value stream consists of the sequence of steps necessary to implement a new concept, which is integrated and deployed via a new or existing system.
This third aspect of systems thinking—understanding and optimizing the full value stream—is the only way to reduce the total time it takes to go from “concept to cash.4 Systems thinking mandates that leaders and practitioners understand and continuously optimize the full value stream, especially as it crosses technical and organizational boundaries.
4. Mary Poppendieck and Tom Poppendieck, Implementing Lean Software Development (Addison-Wesley, 2006).
To address this challenge, value stream mapping provides a systematic way to look at all the steps required to produce value. In so doing, one quickly recognizes that the actual value added steps—the creation of code and components, deployment, validation and so on—consume only a small portion of the total time to market. It then becomes obvious to focus on eliminating or reducing delays between steps to improve cycle time. Figure 5-8 provides an example of a value stream map. In this example, almost all the time between feature request and deployment is wait time—resulting in a highly inefficient process.
Only Management Can Change the System
Everyone is already doing their best; the problems are with the system ... only management can change the system.
—W. Edwards Deming
This Deming quote prepares us for a final set of insights: Systems thinking requires a new approach to management as well, a perspective where managers are problem solvers, take the long view, proactively eliminate impediments, and lead the organizational changes necessary to improve the systems that limit performance. These Lean-Agile leaders do the following:
• Exhibit and teach systems thinking and Lean-Agile values, principles, and practices
• Constantly engage in problem-solving, eliminating roadblocks and improving ineffective internal processes and systems
• Apply and teach root-cause analysis and corrective action techniques
• Collaborate with the teams to reflect at key milestones, and identify and address shortcomings
• Take a long-term view, investing in enabling capabilities such as infrastructure, practices, tools, and training, which provides the foundation for faster value delivery and higher quality and productivity
Understanding these systems thinking aspects helps leaders and teams truly comprehend what they are doing, why they are doing it, and the impact on those around them. In turn, this leads to a leaner and smarter enterprise, one that can better navigate the organization and solution development complexities, leading to better business outcomes.
Principle #3: Assume Variability; Preserve Options
Generate alternative system-level designs and subsystem concepts. Rather than try to pick an early winner, aggressively eliminate alternatives. The designs that survive are your most robust alternatives.
—Allen C. Ward, Lean Product and Process Development
Solution development can be described as the “process of converting uncertainty to knowledge.”5 Development happens in the midst of tremendous variability. Technology and market uncertainty are ever present. But variability is inherently neither bad nor good, as it drives both risk and opportunity. Rather, it’s the type and timing of variability that determines economic value.
5. Dantar Oosterwal, The Lean Machine (Amacom, 2010).
Attempting to eliminate variability too soon may result in poor economic outcomes and a risk-adverse culture, which cannot innovate. (Examples are freezing requirements and design early in the timeline and a culture where every “project” must be a success.) On the other hand, unnecessary variability from routine work should readily be addressed (for example, automated code deployment that eliminates error-prone manual processes). What’s left is the remaining, inherent variability of technology uncertainty.
Set-Based Design
The fundamental understanding that variability is ever present drives teams to develop more effective development practices. One such example is set-based design.
Traditional development practices tend to drive teams to select a single design option quickly and then modify that design until it eventually meets the system intent. “This can be an effective approach, unless of course one picks the wrong starting point; then subsequent iterations to refine that solution can be very time-consuming and lead to a suboptimal design.”6
6. Marco Lansiti, “Shooting the Rapids: Managing Product Development in Turbulent Environments” (California Management Review 38, 1995).
This can be described as a “point-based” approach, as shown at the top of Figure 5-9. Here, a single option chosen up front often results in significant rework and delays that are typically discovered at the end. And the later those problems are discovered, the costlier they are to fix. And the bigger and more technically innovative the system is, the higher the odds are that you chose the wrong starting point!
A better approach is set-based design, as shown in Figure 5-9.
Set-based design recognizes that requirements must be flexible to accommodate economic design choices, and designs must be flexible to support emerging knowledge.
Set-based design manages risk better by considering multiple design options at the start. Thereafter, teams continuously evaluate economic and technical trade-offs—typically as exhibited by objective evidence presented at integration learning points. They then eliminate the weaker options over time and, finally, converge on a final design, based on the knowledge that has been gained to that point.
This process keeps design options open for as long as possible, converges as and when necessary, and produces more optimal technical and economic outcomes.
Principle #4: Build Incrementally with Fast, Integrated Learning Cycles
The epiphany of integration points is that they control product development and are the leverage points to improve the system. When timing of integration points slip, the project is in trouble.
—Dantar P. Oosterwal
This fundamental principle of both Lean and Agile is pivotal to describing the basic mechanism for a new approach to building systems.
In traditional, phase-gate development, investment cost begins immediately and accumulates until a solution is delivered. Often, there is little to no actual value delivered until all the committed features are available or the program runs out of time or money. During development, it is difficult to get any meaningful feedback because the process isn’t designed for it, and the system isn’t designed or implemented in such a way that incremental capabilities can be delivered. The risk remains in the program until the deadline, and even into deployment and initial use.
This process often results in loss of trust between the teams building the solution and the customer. In an attempt to adjust for this, customers and teams try even harder to define the requirements and select “the best” design up front. They also typically implement even more rigorous phase gates. Each of these solutions actually compounds the underlying problem.
The principles of taking an economic view, applying systems thinking and set-based design, informs us that a better approach is to build incrementally, with fast integrated learning cycles. This leads us to the next set of insights.
Integration Points Create Knowledge from Uncertainty
By focusing development on integration points, the Lean-Agile team develops incrementally. The knowledge gained from integration points establishes continuous technical viability. In addition, many integration points can serve as Minimum Viable Products (MVPs) or prototypes that can be released for testing the product in the market, establishing usability, and gaining objective customer feedback. Where necessary, these fast feedback points allow teams to “pivot” to an alternate course of action, one that should better serve the needs of the intended customers.
Integration Points Occur by Intent
Cadence-based integration points become the primary focus of the ART, via both a development process and a solution architecture designed for that purpose. Each integration point is a “pull event” that gathers the various solution elements into an integrated whole, even though it might address only a portion of the system intent. Integration points align stakeholders as well.
Routine synchronization helps assure that the evolving solution addresses the real and current business needs, as opposed to assumptions established at the beginning of the process. Each integration point delivers its own value by converting uncertainty into new knowledge. For example, knowledge of the technical viability of the current design choice and solution is based on objective evaluation of the integrated solutions.
Faster Learning through Frequent PDCA Cycles
Figure 5-11 illustrates how integration points reinforce the basic Plan-Do-Check-Adjust scientific learning cycle developed by Shewhart.7 As we described, these integration points serve as the primary mechanism for controlling the variability of solution development. The system, like science, advances one cycle at a time.
7. Walter Andrew Shewhart, Statistical Method from the Viewpoint of Quality Control (New York: Dover, 1939).
Moreover, the more frequent the integration points, the faster the learning.
In complex systems, local integration points assure that each element, component, or capability is meeting its responsibilities to the overall solution intent. Local integration points for features or components must then be integrated at the next higher system level. The larger the system, the more such integration levels exist. The top-level, least-frequent integration point (for example, a solution in SAFe) provides the only true measure of solution progress.
When the timing of integration points slip, it’s a sure sign of problems and a likely delayed schedule. Even then, this timely knowledge helps facilitate recovery via changes to technical approach, scope, cost, or delivery timing.
Principle #5: Base Milestones on Objective Evaluation of Working Systems
There was in fact no correlation between exiting phase gates on time and project success ... the data suggested the inverse might be true.
—Dantar P. Oosterwal, The Lean Machine
The Problem with Phase-Gate Milestones
Building today’s large-scale systems requires substantial financial investment. Therefore, stakeholders must collaborate to ensure that the proposed return on investment will be achieved throughout the development process versus hoping everything will be okay in the end.
They have to measure progress, too. However, many companies rely on a sequential, phase-gated development process. Progress and control of investments rely on review and approval of completed milestones—discovery, requirements, design, development, test, and delivery.
But there’s an inherent flaw in this model. In most cases, there isn’t a working solution available at the gates to demonstrate the actual progress and solution viability. As a result, true progress isn’t known until the end, when the solution is integrated and tested. Figure 5-12 shows that late discovery of problems is a significant and common problem with the phase-gate approach.
Moreover, as we described earlier, the attempt to define the systems via a point solution early tends to eliminate better design alternatives. Perhaps this is why Oosterwal notes, “the inverse might be true.”
PI Milestones Provide Objective Evidence
Unlike phase-gate development, SAFe PI development milestones include all the steps in the development process—requirements, design, development, and testing—together producing an increment of value. This is done routinely, on a fixed cadence, as illustrated in Figure 5-13.
These PI milestones are used to provide objective evidence as to the viability of the solution in process. The milestones are also used to assess the overall progress against the nearer-term objectives and the roadmap to evaluate the solutions and to inspect and adapt the development process itself.
Principle #6: Visualize and Limit WIP, Reduce Batch Sizes, and Manage Queue Lengths
Operating a product development process near full utilization is an economic disaster.
—Donald Reinertsen
To achieve the shortest sustainable lead time, teams must implement a continuous flow model, allowing new system capabilities to move quickly from concept to deployment. This requires eliminating the project-based funding and organizational model, along with any phase gates that impede flow and can falsely indicate progress.
The three primary keys to implementing flow are
1. Visualize and limit Work-in-Process (WIP)
2. Reduce the batch sizes of work
3. Manage queue lengths
Visualize and Limit WIP
Having too much work in the system causes multitasking and frequent context switching. It overloads the people doing the work and reduces focus, productivity, and throughput. This results in increased wait times for new functionality and unhappy people.
The first step is to make the current WIP visible to all stakeholders. An example is shown in the kanban board of Figure 5-14.
The kanban board shows the total amount of work at each development step and helps identify bottlenecks. In some cases, simply visualizing the current work allows developers to address the systemic problems of too much work starting and not enough flowing and finishing.
The next step is to establish WIP limits and thereby balance the work against the available capacity. When any step reaches its WIP limit, no new work is started until the bottleneck is cleared. Flow increases measurably.
Reduce Batch Size
Another way to improve flow is to decrease the batch sizes of the work. Small batches go through the system faster and with less variability in completion times. That fosters faster learning and faster value delivery.
As Figure 5-15 illustrates, the economically optimal batch size is dependent upon both the holding cost (the cost of inventory and for delaying feedback and value) and the transaction cost (the cost of planning, implementing, and testing the batch).
To improve the economics of handling smaller batches and increase throughput and reliability, it’s essential to reduce the transaction costs associated with any batch. This typically involves increasing investment on infrastructure and test automation, including practices such as continuous integration, test-driven development, and DevOps.
Manage Queue Lengths
The last method to achieve flow is to manage—and generally reduce—queue lengths. Long queues of work are just bad. They create the following:
• Longer cycle times. There’s a longer wait for new items entering the queue.
• Increased risk. The items in the queue, such as requirements, decay over time.
• Increased variability. Each item has some variability, and the more items, the more total variability.
• Lower motivation. A really large queue of work lowers the sense of urgency.
In contrast, reducing queue length decreases delays, reduces waste, and increases quality and predictability of outcomes.
Decreasing Wait Times
Little’s law, the fundamental law of queuing theory, tells us that the average wait time is equal to the average queue length, divided by the average processing rate. (Even the line at Starbucks teaches us that the longer the queue, the longer the wait.)
This also tells us that there are only two options to decrease wait times: reduce the length of the queue or increase the processing rate. Increasing the processing rate—doing things faster—is indeed beneficial, but improvements in processing rates have limitations before impacting quality.
The fastest way to reduce wait times is to reduce the length of the queue. This can be accomplished by keeping backlogs short and largely uncommitted. Visualizing the backlog helps immensely.
In summary, to increase overall throughput, combining the three elements of visualizing and limiting WIP, reducing batch sizes, and managing queues can spark measurable improvements in throughput, quality, customer satisfaction, and employee engagement.
Principle #7: Apply Cadence; Synchronize with Cross-Domain Planning
Cadence and synchronization limit the accumulation of variance.
—Donald Reinertsen
Solution development is an inherently uncertain process. This uncertainty conflicts with the business’s need to manage investment, track progress, and plan and commit to a longer-term course of action. The Lean-Agile approach strives to balance this inherent variability with the certainty needed to enable the business to plan and operate effectively. When it comes to R&D, it’s a balancing act, to be sure.
The primary means to achieve this balance is to use cadence and synchronization, supported by cross-domain planning.
• Cadence transforms unpredictable events into predictable ones. It makes routine that which can be routine. Cadence provides a rhythmic pattern—the dependable heartbeat of the development process.
• Synchronization causes multiple events to happen at the same time. If done on a cadence, it allows multiple development perspectives to be understood, resolved, and integrated simultaneously, thereby limiting deviation from plan to a single time interval.
Figure 5-16 highlights many aspects of cadence and synchronization.
Applying Cadence in SAFe
The SAFe “develop on cadence” mantra illustrates how critical cadence is to the development process. The following are examples:
• Agile teams use a fixed (typically two weeks) cadence for iterations; ARTs and value streams apply a fixed cadence (eight to twelve weeks) for PIs.
• Event calendars are established well in advance. This includes PI planning, system demos, Inspect and Adapt (I&A), and team-level events. This lowers the cost of those events and facilitates planning.
• System and solution integration are frequent and programmatic.
However, Reinertsen also notes that delivering on cadence is another matter entirely, and that requires scope or capacity margin. This means programs need to be careful about planning to meet date-based commitments, including Program Increments (PIs) and other milestones. Some scope or capacity margin (buffer) is required, and you’ll see that in many elements of the SAFe planning and commitment processes.
Applying Synchronization in SAFe
Cadence-based synchronization is applied routinely in SAFe. The following are examples:
• Teams align their iterations to the same schedule to support communication, coordination, and system integration.
• Events such as Scrum of Scrums help manage dependencies.
• ARTs in a value stream align PIs for the same reason.
• System and solution demos integrate components of the system to routinely assess overall viability.
• Routine, cross-functional planning aligns the development teams, business, customers, and suppliers to a common mission and context.
Taken together, cadence and synchronization—and the associated activities—help reduce uncertainty and manage the variability inherent in research and development.
Synchronize with Cross-Domain Planning
Future product development tasks can’t be pre-determined. Distribute planning and control to those who can understand and react to the end results.
—Michael Kennedy, Product Development for the Lean Enterprise8
8. Michael Kennedy, Product Development for the Lean Enterprise (Oaklea Press, 2003).
As Kennedy notes, and as decentralized decision-making (principle #9) implies, centralized planning for significant solution initiatives is problematic. Simply, the complexity is too great, and the facts change too quickly for a centralized planning function to be effective. In its place, SAFe provides for routine, cross-domain, face-to-face planning. This is the glue that holds the entire process together.
There is an additional benefit as well. The most visible example of this is PI planning, where teams and stakeholders from different functional areas gather to plan the work for an upcoming PI, as illustrated in Figure 5-17.
This event is immutable in SAFe. (If you aren’t doing PI planning, you aren’t doing SAFe). PI planning (and in a like manner, pre- and post-value stream planning) is used to do the following:
• Continuously align all stakeholders to a common technical and business vision. Based on the current state, business and technology leaders refine the mission. This aligns all stakeholders to a common mission that describes both near- and longer-term goals.
• Plan and commit to the next program increment. The distribution of planning and control empowers teams to create, within the given constraints, the best possible plans to achieve the best possible solution. But it isn’t just a planning session, as systems requirements and design are continually evolved as well.
There is one additional and significant benefit to this process, which is that periodic planning limits variance from plan to a single time interval, as Figure 5-18 illustrates.
In turn, this means the business has a continuing and updated plan on which they can take the appropriate action.
The development of large-scale systems is fundamentally a social activity, and this planning event provides a continuous opportunity to build and improve the social network that builds the solution. This is such an important topic, that chapter 7, “Planning a Program Increment,” is devoted entirely to the value and mechanisms of PI planning.
Principle #8: Unlock the Intrinsic Motivation of Knowledge Workers
Knowledge workers are people who know more about the work they perform than their bosses.
—Peter Drucker9
9. Peter F. Drucker, The Essential Drucker (Harper-Collins, 2001).
Drucker’s definition of a knowledge worker is a wake-up call for many. With this definition, how can any manager seriously attempt to supervise and coordinate the technical work of people who know more about the work than they do? Indeed, they cannot. Instead, what they can do is to unlock the intrinsic motivation of knowledge workers. Tips for accomplishing this include the following:
• Leveraging systems thinking
• Understanding the role of compensation
• Creating an environment of mutual influence
• Providing autonomy, mastery, and purpose
Leveraging Systems Thinking
Leveraging systems thinking allows knowledge workers to communicate across functional boundaries, make decisions based on economics, and achieve fast feedback about the viability of their solution. They now can participate in continuous, incremental learning and mastery, and they can contribute to a more productive and fulfilling solution development process.
Understanding the Role of Compensation
Many organizations still embrace assumptions about human potential and individual work performance that are outdated. Despite mounting evidence that such measures don’t work and often do harm, they continue to pursue short-term incentive plans and pay-for-performance schemes.
Authors as varied as Pink10 and Drucker11 have each highlighted the fundamental paradox of compensation for knowledge workers: If you don’t pay people enough, they won’t be motivated. But after a certain point, money no longer motivates. In fact, specific monetary incentives can have the opposite effective for knowledge workers.
10. Daniel Pink, Drive: The Surprising Truth About What Motivates Us (Riverhead Books, 2011).
11. Peter F. Drucker, The Essential Drucker (Harper-Collins, 2001).
Lean-Agile leaders understand that neither money nor the reverse—threats, intimidation, or fear—inspire ideation, innovation, and deep workplace engagement. Most specifically, incentive-based practices, such as individual Management by Objectives (MBOs), cause internal competition and can destroy the cooperation necessary to achieve the larger aim. These should be eliminated.
Creating an Environment of Mutual Influence
To effectively lead, the workers must be heard and respected.
—Peter Drucker
An environment of mutual influence fosters motivation and empowerment. Leaders create an environment of mutual influence by giving honest feedback supportively, by showing willingness to become more vulnerable, and by encouraging others to do the following:12
12. David L. Bradford and Allen Cohen, Managing for Excellence: The Leadership Guide to Developing High Performance in Contemporary Organizations (John Wiley & Sons, 1997).
• Disagree with respect and where appropriate.
• Advocate for the positions they believe in.
• Make their needs clear and push to achieve them.
• Enter into joint problem solving, with management and peers.
• Negotiate, compromise, agree, and commit.
Providing Autonomy, Mastery, and Purpose
It appears that the performance of the task provides its own intrinsic reward ... this drive ... may be as basic as the others....
—Daniel Pink, Drive: The Surprising Truth About What Motivates Us
Daniel Pink’s work, and the work of many others, helps us understand that there are three primary factors in establishing deep workplace engagement: autonomy, mastery, and purpose.
• Autonomy is the desire to self-direct, to manage one’s own life. Simply, when it comes to knowledge work, self-direction is better.
• Mastery is the inherent need for people to grow in their careers and acquire new skills that allow them to provide ever higher levels of contribution.
• Purpose is the need to make a connection between the aim of the enterprise and the worker’s daily activities. This makes the work more meaningful and links the worker’s personal goals to the company mission.
Lean-Agile leaders need to understand these paradigms and strive to continuously create an environment where knowledge workers can do their best work.
In summary, we live in an age where knowledge workers outnumber management, are as smart or smarter, and have more local context. Unlocking their intrinsic, raw potential is a significant factor in improving the lives of those doing the work, as well as providing better outcomes for customers and the enterprise.
Principle #9: Decentralize Decision-Making
Knowledge workers themselves are best placed to make decisions about how to perform their work.
—Peter F. Drucker
Delivering value in the shortest sustainable lead time requires decentralized decision-making. Any decision that must be escalated to higher levels of authority introduces a delay in delivery. In addition, escalated decisions can decrease the effectiveness of decisions because of the lack of local context, plus changes to facts that occur during the waiting period.
Simply, decentralized decision-making reduces delays and improves product development flow and throughput. It enables faster feedback, more innovative solutions, and higher levels of empowerment.
Centralize Strategic Decisions
This is not to say, however, that all decisions should be decentralized. Some decisions are strategic, have far-reaching impact, and are largely outside of the team’s responsibility. After all, leaders still have accountability for outcomes. And they have the market knowledge, longer-range perspectives, and understanding of the business and financial landscape necessary to steer the enterprise.
This leads us to an understanding that some decisions should be centralized. Generally, these decisions are as follows:
• Infrequent. These decisions aren’t made often and typically are not urgent. Deeper consideration is appropriate. (Examples are product strategy and international commitments.)
• Long lasting. Once made, these decisions are unlikely to change. (Examples are a commitment to a standard technology platform and a commitment to organizational realignment around value streams.)
• Provide significant economies of scale. These decisions provide large and broad economic benefit. (Examples are a common way of working, standard development languages, standard tooling, and offshoring.)
Leadership is charged with making these types of decisions, supported by the input of those impacted by the decisions.
Decentralize Everything Else
The vast majority of decisions do not reach the threshold of strategic importance. Therefore, all other decisions should be decentralized. These types of decisions are typically as follows:
• Frequent. These decisions are frequent and common. (Examples include team and program backlog prioritization and response to defects and emerging issues.)
• Time critical. A delay in these types of decisions comes at a high cost. (Examples include point releases, customer emergencies, and dependencies with other teams.)
• Require local information. These decisions need specific local context, whether it be technology, organization, or specific customer or market impact (Examples include a decision to ship a release to a specific customer, resolve a significant design problem, and self-organization of individuals and teams to an emerging challenge.)
The workers who have better local context and detailed knowledge of the technical complexities of the current situation should make these decisions.
A Lightweight Thinking Tool for Decision-Making
Understanding how decisions are made is a key factor in empowering knowledge workers. Leadership’s responsibility is to establish the rules for decision-making (including, for example, the economic framework) and then largely empower others to make them. Figure 5-19 provides a simple tool and exercise for thinking about whether decisions should be centralized or decentralized.
Summary
This chapter described SAFe’s principles, which are the core beliefs, truths, and economic values that drive effective Lean-Agile roles and practices.
The key takeaways from this chapter are as follows:
• Principles are enduring. They stand the test of time and can be applied universally no matter the situation.
• A practice is a specific activity, action, or way of accomplishing something. A practice that works in one situation may not necessarily apply or work in another. That’s why we need principles.
• SAFe is based on nine Lean-Agile principles:
1. Take an economic view.
2. Apply systems thinking.
3. Assume variability; preserve options.
4. Build incrementally with fast, integrated learning cycles.
5. Base milestones on objective evaluation of working systems.
6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths.
7. Apply cadence; synchronize with cross-domain planning.
8. Unlock the intrinsic motivation of knowledge workers.
9. Decentralize decision-making.
• Before you can effectively apply SAFe, you need a deep understanding of the principles to know how and why SAFe works.
• The principles themselves are a system, and the whole is greater than the sum of the parts.