Preface

Despite the widespread success of Scrum as an agile software delivery framework, many organizations struggle to scale development beyond the individual team level, and quickly discover that additional operating practices are needed to plan and coordinate the work for large, multi-team programs.

Several frameworks have emerged to tackle the scaling challenge, and the Scaled Agile Framework (SAFe) has established itself as one of the most popular and widely adopted. According to their website, SAFe has been adopted by over 70 percent of US Fortune 100 companies. Access to certified training and support resources is widely available, and this factor can substantially improve the likelihood of successful adoption.

SAFe is a large, complex, and evolving framework, and comes with a large and expensive learning curve. SAFe has its own unique lexicon of Agile Release Trains, Planning Increments (PI’s) and Architectural Runways. It takes time to understand these concepts, decide which ones you need, and leverage them in an effective way to support the specific needs of your organization.

Organizations are encouraged to engage the services of SAFe Practice Consultants (SPCs – trained and certified by Scaled Agile Inc.) to provide implementation guidance and coaching. A key question is – what are the core practices needed to get started – what is the simplest thing that could possibly work? Is there a simple baseline pattern, or template, that can be used as a starting point, but still enables organizations to quickly deliver value at scale?

My advice is to learn enough about SAFe so that you can at least have well-informed discussions with your teams, and to equip you to be able to select the right consultants to help guide any initiatives around SAFe adoption. Investing a little effort to learn the basics pays off in terms of not wasting time on initiatives that do not deliver or hiring unqualified consultants.

This book is the result of my own firsthand experiences in helping organizations to scale. My aim is to save you time and effort by providing a clear and easy guide to the SAFe framework. This book will arm you with the knowledge to engage productively with SAFe consultants, and help you better articulate your scaling needs. For those who want to jump right in and begin building or experimenting with their own implementation, this book is a hands-on, step-by-step guide to get you started.

This iteration of the book has been updated to incorporate changes brought with the release of SAFe 6.0. Several changes to terminology associated with PI Planning have been made, for example, Program Increments are now called Planning Increments, SPCs are now SAFe Practice Consultants, and Scrum Masters can use the term Team Coach. Beyond the changes in terminology, no fundamental changes have been made that impact the PI Planning process or the basic delivery model.

How This Book is Organized

• Chapter 1. Introduction to the Scaled Agile Framework. This provides an overview of the SAFe framework.
• Chapter 2. Organizing for scaled delivery. Describes the organizational prerequisites for successful SAFe adoption.
• Chapter 3. Constructing an ART Backlog. The ART Backlog is the starting point for PI Planning. This chapter describes how to create a backlog that is aligned with product vision and strategy and has product features sufficiently well-refined to support PI Planning.
• Chapter 4. PI Planning Step-By-Step, takes you through each of the basic steps of planning a PI.
• Chapter 5. PI Execution Practices explains the essential roles, practices, and artifacts necessary for successful execution and delivery throughout a PI.

1. Introduction to SAFe

Core Ideas

• Business Agility: The ability to sense and respond quickly to market changes and emerging opportunities. “Operating at the speed of change” requires adaptable organizational structures, and broad operational agility, not just faster projects.
• SAFe as an operating system for Business Agility. The Seven Core Competencies of Business Agility: 1) Team & Technical Agility, 2) Agile Product Delivery, 3) Enterprise Solution Delivery, 4) Lean Portfolio Management, 5) Organizational Agility, 6) Continuous Learning Culture, 7) Agile Leadership. 
• Flow as the leading indicator of value. Flow metrics: WIP, flow time, throughput, predictability, and time-to-value beat output metrics for guiding decisions

Business Agility

Business Agility is the ability to engage and prosper in the digital era by adapting swiftly to market changes and new opportunities with creative, digitized business solutions. It involves a combination of technology, leadership, culture, and processes that allow businesses to quickly adapt to market changes and to continuously deliver value to customers. Key components include customer-centricity, adaptive planning, cross-functional collaboration, and a focus on speed and learning.

Key aspects of business agility in the digital age

• Customer-centricity: Agile businesses prioritize understanding and responding to customer needs quickly, aiming to create superior experiences.
• Rapid Response: Market disruption is the norm. The ability to quickly develop and launch new digital products and services is crucial for staying competitive.
• Strategic Adaptability: Strategic agility involves continuously reassessing priorities and adapting long-term vision based on market feedback and emerging opportunities.
• Operational Agility: Operational agility means extending agile principles beyond software teams to other functions like HR, finance, and marketing, often using cross-functional teams and adaptive budgeting.
• Cross-functional Collaboration: Breaking down silos to foster closer ties between departments allows the entire organization to focus on delivering value rather than on functional goals.
• Continuous Delivery: Regularly delivering value to customers through frequent, incremental outcomes and shortening feedback loops is a hallmark of agile organizations.
• Dynamic Workforce: Cultivating a workforce that is ready to adopt new digital technologies is essential for successful and sustained digital transformation.

The Seven Core Competencies

The Seven Core Competencies of SAFe constitute a framework for the broader goal of Business Agility – not just for scaling software delivery. Each core competency has Values & Principles, Roles & Responsibilities and Key Practices. Here’s a summary:

• Lean-Agile Leadership is the foundation of the entire framework. This competency area emphasizes the necessity for an organization’s leadership to understand and exemplify Lean-Agile Principles in their leadership behaviors.
• Team & Tech Agility: Accelerating value delivery. Small cross-functional teams, with the ability to deliver working increments of a product or solution as the output of every iteration – using the important principle of building quality in.
• Agile Product Delivery – defines a delivery model using teams-of-teams – known as Agile Release Trains (ARTs), operating in fixed-width timeboxes (PIs) to plan and deliver solutions. DevOps and the Continuous Delivery Pipeline creates the foundation that enables the release of value, in whole or in part, at any time it’s needed.
• Enterprise Solution Delivery provides an additional layer of governance for creating large solutions requiring the capacity of multiple Agile Release Trains.
• Lean Portfolio Management – agility at the strategy level. This is where we connect strategy to execution using Lean Budgeting as an adaptive approach for investment funding among multiple value streams in a portfolio. LPM helps organizations better align portfolios and portfolio strategy with investments and broader business strategy. Done successfully, this helps optimize portfolio value flow.
• Organizational Agility: the ability of an organization to sense and quickly respond to threats and opportunities in fast-changing business environments. Everyone delivering solutions has received training in lean and agile methodologies and embraces its principles, values and practices.
• Continuous Learning Culture: is about how Organizations must embrace continuous improvement as a way of life, and where everyone in the organization must be involved in change & continuous improvement. This is accomplished through establishing a learning organization committed to continuous improvement and development, fostering a culture of innovation.

Flow Metrics

Our ultimate goal is to deliver maximum value at minimum cost. We seek to achieve this via a relentless focus on Cycle Time reduction – Cycle Time is a proxy for cost. The cost to produce an item is directly proportional to the amount of time it spends in the system. Thus, reducing Cycle Time reduces operating costs.  The basic measures of flow are Cycle Time and Throughput, and the levers of flow (controllable leading indicators) are WIP (Work In Process) and Work Item Age. 

The fundamental measures of flow are:

• Cycle Time: The elapsed time between when work on an item starts and when it is done.
• Throughput: The number of items finished per unit of time (per day, per week, per sprint and so on).
• WIP: The number of items in progress – started but not finished.
• Work Item Age: The amount of time between when work on an item started and the current time: how long an item has been in progress.

Work Item Aging and WIP are leading indicators and these are the measures that teams should focus on daily in order to proactively manage the flow of work. 

Cycle Time and Throughput are lagging indicators (the data is based on work that has already been completed). These are historical data which can be input to Monte Carlo and applied for planning and forecasting purposes. Cycle Time addresses: When will it be done, and Throughput addresses: How much can we do. In both cases, the measures are expressed as a range plus a probability. 

More details on Flow Metrics in Appendix E.

Challenges in achieving business agility

• Leadership and culture: The biggest challenges often lie in leadership’s ability to manage change and in the overall company culture.
• Organizational structures: Unsuitable structures, practices, and processes can hinder agility.
• Mindset: A resistance to change and adopting new ways of thinking can be a significant obstacle.

2. Organizing for Scaled Delivery

•  ART Design – Organizing around value.
• ART Roles
• ART Events and Cadences
• ART Launch

Traditional Structures Impede Agility

 Getting the right organizational structure in place is a critical prerequisite for successful scaling.

Traditional functional silos do not scale and create flow-impeding dependencies between teams. A value stream mapping exercise can help ensure teams are focused on customer value delivery, have clear missions, and can operate with minimum dependencies. The best delivery performance in terms of throughput and delivery cycle time is achieved with small, autonomous, cross-functional teams that can independently deliver deployable product features and capabilities.

Teams are the fundamental units of delivery within an agile organization. In Scrum, teams exist to produce working increments of a product as the output of every sprint. Each increment represents a step towards achieving the Product Goal.

To participate effectively in PI Planning, teams must be able forecast the rate at which they can translate their backlogs into working software.

Agile delivery teams must:

• Be cross-functional: Have all the skills needed to produce value as the output of every sprint.
• Be able to define, refine, and estimate product backlogs.
•  Operate with a stable velocity or throughput.
•  Reliably produce working increments of the Product to a Definition of Done.

If individual delivery teams in an organization are unable to perform these basics, then the enterprise will be incapable of anything that resembles agile delivery. If an organization is not agile at a basic team level, it’s going to be difficult to be agile at scale. 

Teams can be impeded by legacy organization structures designed around functional silos that cause dependencies, hand-offs, and resulting delays. The ideal agile team is small: a maximum of around 10 people. Small teams will have less planning overhead, operate with less WIP, and can make decisions faster. It is easier to build high levels of trust within a smaller team, which can lead to more risk-taking and innovation.

ART Design – Organizing Around Value

 One of the most consequential actions an organization can take is to re-align their work around business value streams. A value stream is the sequence of activities performed by a business unit to deliver a product or service to a customer. Even if they are not always aware of it, all organizations have a value stream associated with each product or service they provide.

A value stream is the collection of activities necessary to produce and deliver a product or service (SAFe uses the term solution to cover both) to a customer. Value stream analysis identifies those activities that directly contribute to customer value creation. Non-value adding activities, for example, those associated with the lean waste categories (overproduction, defects, moving goods around, inventory management), are excluded. Activities in the value creation workflow are supported by interconnected systems, subsystems, or individual applications. Each of these is in turn supported by one or more development teams. For example:

This example shows a value stream aligned team structure for a software development organization that supports a business value stream. Each team is aligned with a specific activity within the value stream – for example, the team focused on search in an eCommerce business can independently develop user-facing features related to that activity. Each team is focused on a specific aspect of the value stream but at the same time all teams are collectively aligned on a common product goal and vision. Large enterprises may operate a portfolio comprising multiple business units or product units, each with their own value stream.

Here’s a more detailed example for an organization that operates an eCommerce business:

 Each individual step in the value stream, or each customer touchpoint, should add measurable value. When each part of the business value stream is complex it may be necessary for different teams to focus on different parts of the system. This allows teams to focus on a smaller subset of the problem domain and avoid cognitive overload. These teams are often referred to as feature teams. If we use an eCommerce system as an example, we might have one team focused on search, another on shipping and perhaps another on payments. In addition, there may be cases where deep specialist skills are required (e.g., data analytics, or complex search algorithms), and these skills may be organized into a subsystem team for that purpose. In either case both feature teams and subsystem teams will have their own backlogs and their own Product Owners. A SAFe Agile Release Train (ART) is based on this model.

Value stream-based delivery differs from traditional project models in several ways:

• Based on dedicated teams, with longevity and stability, focused on a long-term product vision, instead of temporary groups organized around short-term projects.
• Long-lived teams develop deep domain knowledge and can deliver at much higher productivity or throughput.
• Productivity is maximized by minimizing dependencies and handoffs between teams.
• Long-lived teams are better positioned to develop greater improvements to their delivery effectiveness through the process of continuous improvement.

Organizing around value delivery is an effective way to dismantle functional silos and to remove dependencies within an organization.

ART Roles

 If the value stream is supported by more than just a few (2-3) teams, then we may need to scale both the Product Owner and Scrum Master Roles. In this case we will ideally have one PO and one SM per team but will also need additional support to manage the scaled product (ART) backlog, and to help orchestrate and synchronize the planning and delivery activities across multiple teams. (Note, these are roles, not job titles. Individual organizations will have organization-specific titles for these roles).

Product Manager: Owns and prioritizes the ART Backlog. Responsible for ‘what gets built’. Works with customers and internal stakeholders to understand their needs and provide clarity and direction for the delivery teams.

Release Train Engineer (RTE): Facilitates all value stream governance events (PI Planning, ART Syncs, System Demos), takes the lead on impediment removal, and is responsible for ensuring the organization is continuously improving its performance.

System Architect: Defines the overall architecture of the system. Identifies architectural runway needs, non-functional requirements, and system interfaces.

The distribution of responsibilities between Product Manager and Product Owner breaks down as follows.

Product Manager vs. Product Owner

The Release Train Engineer (RTE) role supports any additional orchestration needed to support PI Planning and execution beyond the team level, and responsibilities between RTE and Scrum Master break down as follows:

Release Train Engineer vs. Scrum Master Responsibilities

 This organizational pattern is not intended to represent a hierarchy. Any Product Owner and Scrum Master from any of the teams could potentially play the role of Product Manager or RTE (and vice-versa).

ART Events and Cadences

• ART Cadence – ARTs operate on a recurring fixed cadence of 5-6 Iterations per PI. Within a PI, teams run on the same iteration cadence. and deliver potentially releasable solution increments as the output of every iteration.
• System Demos: Completed features are demonstrated at the end of each iteration.
• Innovation & Planning (IP) Iteration at the end of each PI provides a buffer to complete unfinished work, conduct the PI Inspect and Adapt event for the PI and time to plan the next PI.
• PI System Demo. The PI system demo takes place at the end of each PI during the IP iteration and is intended to showcase all features developed across the entire PI, acting as the first part of the Inspect & Adapt event to review progress against PI Objectives.  
• PI Planning for the next PI occurs within the IP iteration.
• Team Cadence – Within a PI, teams run on the same iteration cadence, that is, all iterations start and finish on the same schedule.  Teams deliver potentially releasable solution increments as the output of every iteration.

ART Launch

Once an ART has been designed for a value stream the organization should finalize the steps needed for ART launch and mobilization. These are summarized below.

 Team Readiness. Team rosters should be reasonably complete, with the roles of Product Owner and Scrum Master identified for each team. Team size should be a maximum of around 10, including PO and SM. Teams need to be able to sprint. That is, be able to plan and deliver working, tested software, or product increments consistently. It is important that teams acquire a stable velocity as a priority. This is an important factor for successful PI Planning, and vital for the overall performance of the ART.

ART Readiness. ART readiness will include having key ART roles in place (Product Manager and RTE) and defining ART events and cadences. When ready, the RTE should schedule the first PI Planning event and the Product Manager should create an ART Backlog.

ART Kickoff Event. Hold a kickoff event to communicate the mobilization of the ART. This could be a town hall type of event (either live or virtual), with all the teams, ART leadership, business stakeholders and other partners. The event is led by the ART Product Manager or other senior leader and facilitated by the RTE. Topics covered should include the ART vision, strategy, success factors and any near-term business objectives. Present the team structure (list of teams and associated missions if any) and any newly appointed Product Owners or Scrum Masters, along with the names of the people in the key ART roles. Announce the first PI Planning event and the work needed to prepare for it, including any training that will be offered on the actual planning process.

3. The ART Backlog

 Topics covered in this chapter:

•  The role of the ART Backlog.
• ART Backlog Refinement and PI Planning Readiness.
• ART Backlog Ranking using WSJF.

Enjoying the sample? Get the eBook