Considering the framework and principles together

The Full SAFe graphic and SAFe principles make more sense when you look at them together. I like to think of them in terms of process and principles:

• The SAFe framework (see Figure 4-1) is the overall process that organizations follow to transform into agile enterprises.
• The nine principles govern the way individuals and teams throughout the organization do their jobs.

When you embark on using SAFe for the first time, it’s usually better to start with the framework before adopting the principles. In other words, consider what your organization will look like as a SAFe agile enterprise before tackling the way everyone’s mindset and behaviors will change.

Taking a bird’s-eye view of the Full SAFe graphic

When you look at the Full SAFe graphic for the first time, note the following four areas:

• Enterprise: In the upper-left corner of the graphic is “Enterprise,” which represents the organization in two ways:
  • “Enterprise” is in the top-left corner for a reason — it’s the top of the SAFe food chain, the source of all business vision and strategy, funding, and governance.
  • Note that the box around “Enterprise” extends around everything else, indicating that the enterprise is the entire organization.
• SAFe management levels: The better part of the graphic is devoted to the four SAFe management levels: Portfolio, Large Solution, Program, and Team. I describe the levels in a little more detail in the next section and in a lot more detail in the later section, “Stepping Through the SAFe Management Layers and Levels.”
• The foundation: At the bottom of the graphic is a gray bar that represents the foundation on which the SAFe framework rests. It includes Lean-Agile Leaders, Core Values, Lean-Agile Mindset, and SAFe principles.
• The spanning palette: The bar on the left contains tools used to develop and deliver products through the SAFe methodology, including Metrics, Shared Services, Milestones, Roadmap, and Vision. For more about the spanning palette, see the later section, “Filling in the background with the SAFe spanning palette.”

Brushing up on SAFe framework fundamentals

The Full SAFe configuration is divided into the following four management levels:

• Portfolio: At this level, you find the principles, practices, and roles for creating and managing value streams. A value stream is a series of steps for building solutions that deliver value to a customer continuously. The people and processes that reside in the Portfolio level are responsible for building solutions that enable the enterprise to meet its strategic objectives.

• Large Solution: This level contains the roles, activities, and artifacts (byproducts of the development process, such as a user story) to build large-scale solutions beyond the scope of what a single agile release train (ART) can develop.

  An ART is a team of teams, which you find at the Program level (discussed next). At the Large Solution level, you find solution trains (teams of teams of teams). A solution train may have dozens of ARTs, each having 5 to 12 agile teams.

• Program: At the Program level are the roles and activities necessary to deliver solutions continuously via ARTs. This is where agile teams, key stakeholders, and other resources conduct their ongoing mission to develop and deliver solutions. Each ART is composed of 5 to 12 agile teams. (The “train” in ART is based on the idea that this train is always moving on time; you can pile features into the backlog, and the train will fit them into the product incrementally, so no team needs to wait for another team to complete its work.)
• Team: At this level, each team (five to nine team members) is dedicated to defining, developing, testing, and delivering a quality end product. Every team at this level is part of an ART at the Program level.

For more detailed coverage of these four layers, see the later section, “Stepping Through the SAFe Management Layers and Levels.” Here’s how the framework functions in practice:

1. At the Portfolio level, high-level business leaders break down value into a backlog (a prioritized list what’s needed to deliver the desired value), which is then broken down into epics (high-level business cases); for example, “create a version of our software that works with Apple products.” (A single epic may spawn more than one product or solution.)
2. At the Large Solution level, engineers work with the customer to deliver large and complex solutions. This might be a software program with several different areas of functionality. The teams work together to create a solution train that helps align people to a common vision, mission, and backlog.
3. At the Program level, leaders break down the epic from the portfolio backlog to create a program backlog (a prioritized list of product features). A feature may require one team or several teams based on its size and complexity. If several teams are required, they function within the construct of an ART.
4. At the Team level, each agile team pulls projects from its program backlog in order of priority and completes them within a specified period of time.

With SAFe, an organization’s value to the customer is defined at the enterprise level and broken down into smaller and smaller units of value at each level of the framework from portfolio (at the top) to team (at the bottom). Each of these levels refines the epic to ensure that the organization continuously delivers the highest value to the customer.

Getting to know the nine SAFe principles

SAFe has nine principles that govern the way everyone in the organization approaches product development:

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.

Don’t focus on these principles just yet. Their significance and application may be difficult to grasp at this point. It’s a bit like looking at the lyrics of a song before you decide if you like the music. Consider reviewing the principles after you have a better understanding of the framework.

Reinterpreting “lightweight”

At first glance, SAFe may appear too big to be agile, but its size serves a practical purpose. If you have a large product with hundreds of developers, then coordinating dozens of agile teams becomes increasingly difficult. Also, if you have several smaller products that all depend on each other, then you need some way to communicate a common vision. You don’t want one product to be completely different from every other product you’re delivering.

If you’re a large organization, and you’re stumbling through a hybrid approach, attempting to combine agile with traditional top-down management (see “Avoiding water-agile-fall” later in this chapter), then SAFe’s guidance can be useful.

Being realistic

The reality is that many organizations already have one foot in waterfall (top-down management) and another in agile (bottom-up management). What SAFe does (and does really well) is offer a shared set of best practices for what such an organization is already doing. In one sense, SAFe normalizes this water-agile-fall approach, even though this approach may not be benefiting your organization. On the other hand, SAFe may be the only form of the agile mindset that your organization will accept — the only way to infuse some creativity into a large rigid process.

Either way, SAFe is very reasonable in the context of the problem it’s trying to solve. The framework assumes that your teams can’t deliver an enterprise-level product using the bottom-up approach that’s inherent with an agile team. In a sense, SAFe is built on the premise that a cross-functional, self-organized agile team doesn’t scale well when you’re developing larger products.

Giving managers more authority

The solution to the problem of trying to develop large, complex products with small, self-organized agile teams is to take some authority and self-direction away from the teams and create communities of teams that work together and follow a common path. Manager-style roles in these communities can help prioritize work and set direction.

SAFe is a compromise; it’s not just another top-down process to control your teams, nor is it fully consistent with an agile mindset. The framework contains plenty of fixes to help decentralize management, which helps it avoid the top-down, command-and-control approach in waterfall frameworks. SAFe also features plenty of practices to help ensure agile teams have as much creative flexibility as possible.

If you see this framework as a set of compromises, then your teams can get a lot of value from following SAFe. The framework gives you the convenience of trying to fit agile into your enterprise instead of the other way around. For many organizations, SAFe is the best place to start.

Recognizing the flaw: Planning over adapting

Software developers who tried Royce’s waterfall approach soon discovered that it was fundamentally flawed. During the planning, software features changed so frequently that many companies ended up delivering a product that was completely different from the idea they started with. All the time and effort spent planning was wasted.

Mixing the worst of both worlds

To address this weakness in the model, many organizations began encouraging a more agile mindset so that the software development teams could quickly pivot and modify the product to better fit their customers’ needs. However, most organizations that embraced the more responsive agile approach refused to let go of the more predictable waterfall approach. As a result, many organizations ended up with a hybrid, often referred to as water-agile-fall. You might hear it called the “hybrid approach” or “mixed methodology,” but the construct is the same: You have a waterfall organization with agile teams.

This hybrid approach allows development teams to have much more flexibility to design, code, and test even when much of the product has already been planned and analyzed. However, these same teams are pressured by the top brass to deliver a well-planned product on a specific release date. A team might be free to create the minimum viable product, but that well-planned product must be delivered on time and within a set budget.

In many ways, water-agile-fall is the worst of both worlds. Time spent planning is wasted, because everything is subject to change, and developers have a tough time being agile when the product is (or is perceived to be) inflexible.

Introducing a “SAFer” approach

Even though water-agile-fall is less than ideal, many organizations insist on it. This is where SAFe really shines, because it gives organizations the best of both worlds. It accepts the reality of how most large organizations approach agile. Then it takes the best practices of this mixed approach and bundles them into a comprehensive enterprise framework.

As you can imagine, this hybrid approach has a lot of compromises. In many cases, most large enterprises would do better either transitioning to agile or trying to improve their existing waterfall arrangement. For organizations that are currently following a water-agile-fall approach, SAFe is a more effective model that’s easier to transition to. Large organizations have no reason to reinvent the wheel when they have so many best practices and compromises bundled into SAFe. The SAFe team has worked for years to fine-tune its framework to deal with the exact challenge these water-agile-fall organizations struggle with. Why not take advantage of the team’s hard work?

Meeting the key players

The Portfolio level includes three distinct roles (which can be held by several people):

• Epic owners: Define, coordinate, and facilitate implementation of high-level epics (business cases, such as introducing a new product, merging with another company, or responding to marketplace changes).
• Enterprise architects: Provide the strategic technical direction, which may include recommending the development and delivery of technology stacks, application programming interfaces (APIs), and hosting strategies, and facilitating the reuse of ideas, components, services, and proven patterns across a portfolio’s solutions.
• Lean portfolio management: Typically the business managers and executives who are responsible for the highest level of decision-making and financial accountability related to the portfolio’s success.

Prioritizing epics and adding them to the backlog

The Portfolio level is where management formulates large business initiatives for the organization, considering such things as new business opportunities, mergers and acquisitions, problems with existing solutions, marketplace challenges, and so forth. Here, all big ideas are welcome. Ideas are then reviewed, analyzed, and added to the portfolio backlog (a prioritized list of major initiatives) for execution.

Portfolio managers use a Kanban board, as explained in the next section, to help determine what gets added to the backlog.

USING A KANBAN BOARD

A Kanban board is a swim-lane diagram that shows the progress of proposed and approved epics (initiatives or tasks), as shown in Figure 4-5. Progress is usually indicated by the column labels “Funnel” (where all ideas/epics are listed), “Review,” “Analysis,” “Portfolio Backlog,” “Implementation,” and “Done.” (See Chapter 8 for more about Kanban.)

In SAFe, you break down the work into the smallest possible chunks. At this stage, these chunks are epics. You can then prioritize the epics to decide where to place them in the backlog.

STARTING THE WEIGHTED SHORTEST JOB FIRST

A common way to prioritize items in the backlog is to do the weighted shortest job first (WSJF). To determine which is the weighted shortest job, calculate the cost of delay (CoD) and divide that by the job duration. For example, if you’re working on a product that will generate $50,000 per month for the company, CoD is $50,000 per month, because the company will lose $50,000 every month the product is delayed. (You could divide that figure by 4 to determine the weekly CoD or by 30 to calculate the daily CoD.) To determine WSJF, you divide that figure by the duration of the project, so if the CoD is $50,000 per month, and the project will take eight months:

If you have two 12-month projects, one of which will generate $5 million in revenue and the other $500,000 in revenue, the CoD for the first project has a much greater return for the same duration, so its weight is also greater and you do that job first.

Unfortunately, the expected economic impact may be unknown. Fortunately, the WSJF criteria can be relative. All you need is relative scoring to support prioritization. It’s similar to the relative estimating you do for Scrum projects (see Chapter 1). You can balance a bunch of elements, including business value, time pressure, and risk reduction or opportunity enablement, to come up with a cost of delay. Then you divide that by the job size to determine its relative weight. So, in general, the highest priority job would take very little time to complete and add a lot of business value.

Some organizations like to use the same planning poker group decision-making process you see in Scrum to come up with the cost of delay and job size (see Chapter 1). Others may use a spreadsheet to come up with ballpark estimates and may even break down their estimates into CoDs for several areas, such as business value, time pressure, and risk removal. Some just use two estimates: one for CoD, the other for duration, and the two together to calculate WSJF using the earlier formula.

ADDING NONFUNCTIONAL REQUIREMENTS TO THE BACKLOG

Nonfunctional requirements (NFRs) are constraints or restrictions that apply to all items in the backlog (see Figure 4-6). For example, an NFR may be that all items must comply with the Healthcare Insurance Portability and Accountability Act (HIPAA) security standards or that all software must be written in a certain version of Java.

You can see that NFRs are a constraint on the backlogs at all of the management levels. SAFe is reminding you that you can't spend all of your adding features. The framework forces you to also consider reliability, performance, and supportability. In a sense, you shouldn’t always be focused just on cooking the meal. Sometimes you need to spend a little more time setting the table.

Financing value streams with Lean Budgets

Another way portfolio managers prioritize work and prevent any team from becoming inundated is through Lean Budgets — a set of practices for funding value streams rather than projects (see Figure 4-7). Remember that SAFe takes a transactional view of how people work in an enterprise. So, when the portfolio management team assigns a budget to a value stream, what it’s really saying is, “You’re welcome to work on whatever you want, but this is the only thing we’re going to pay you for.”

Shifting the focus from projects and products to value streams

While the Portfolio level has many components, its primary focus is on the value stream. The steps involved vary depending on the product and how the organization delivers the product to the customer, but it’s triggered by some event such as the customer placing an order, and it ends when the customer receives the product or some other value (see Figure 4-8). The steps in the middle are the actions the team needs to take to deliver that value. Maybe the team must meet to develop a vision for the product and then develop, test, and tweak the product before releasing it. Each of those actions is a step in the value stream.

Value streams are a central part of Lean budgeting, which focuses the attention of everyone in the organization on financing these value streams. In addition, all key performance indicators (KPIs) are tied to value streams, so performance is measure by the value delivered to customers and how efficiently and cost-effectively that value is delivered.

Within the value stream are epics and enablers:

• Epics: The products or solutions customers value.
• Enablers: The tools that deliver the information and insight in support of the development and delivery of value. SAFe recognizes the following four types of enablers:
  • Exploration: To validate the need or the solution
  • Architectural: To pave the architectural runway — the code, components, and technical infrastructure for implementing features
  • Infrastructure: To develop, test, and integrate initiatives
  • Compliance: To prepare compliance activities

Making value streams Lean

SAFe relies heavily on Lean thinking, which emphasizes minimizing waste while maximizing value, or finding the most efficient path to deliver what customers value. Making a value stream Lean is a two-step process:

1. Identify what the customer deems most valuable.
2. Optimize the process for delivering that value to the customer.

Lean is a concept that came out of the Toyota Production System and was originally used in automobile manufacturing. Software developers later adapted it and created Lean Software Development.

STREAMLINING THE VALUE STREAM

After you’ve identified a customer and the value you deliver to that customer, it’s time to streamline your value streams, which you can do in several ways, including the following:

• Remove unnecessary steps from the value stream.
• Make existing steps in the value stream more efficient.
• Reduce queue time by breaking the steps into their smallest possible components and distributing them.

You can see examples of value stream optimization by standing in line at your local grocery store. In the past, the checkout clerks had to key in the prices of each item. With the use of barcodes and scanners, that step has pretty much been eliminated. The step of having to weigh produce hasn’t been completely eliminated, but it has been made more efficient by building a scale into the scanner mechanism. And if lines start to get too long, a manager will open additional lanes to move customers through the checkout process faster. All of these are ways to optimize the value stream.

Amazon’s grocery stores have streamlined the value stream even more by completely eliminating checkout lines. A customer logs in to the store by tapping her smartphone on a turnstile when she enters the store, and as she adds items to her cart, they’re entered into the customer’s virtual cart app, which then totals the bill and charges it to the shopper’s credit card as she exits the store.

In SAFe, value-stream optimization is based primarily on queueing theory, specifically Little’s Law, which postulates that the best way to get something through a complex system is to split it up into the smallest possible chunks. The idea is that several short lines will go through a system faster than one long line.

Imagine that your work was set up like the water tank pictured in Figure 4-9. The “L” represents the water in the tank. You can think of it as the work in progress (WIP). The “λ” is the spout coming out of the tank. It’s your team’s throughput — the amount of work the team can finish (your constraint). The “W” is the lead time. This is the amount of time it takes for work to go through the whole system.

Imagine that your team’s throughput “λ” is two gallons per day. That means five gallons in the tank will give you a lead time of 2.5 days:

Now image that there are 30 gallons in the tank. This will give your team a lead time of 15 days:

A shorter lead time will make your work more predictable and give your customer a greater opportunity to provide feedback. That means you want to break your work down into the smallest possible chunks and have it flow through the system at a protectable pace. In this case, you wouldn’t want to keep any more than five gallons of work in the tank at any one time.

Don’t try to cram big chunks of work, especially unplanned work, into the value stream. Doing so may make you feel as though you’re getting a lot done, but this will cause bottlenecks that can grind development to a halt. Just look at what happens on a highway when a few drivers try to rush to the front of the line and merge in front of everyone else. Some entrance ramps even have traffic “metering” lights for flow control to prevent a line of traffic from trying to merge all at once or trying to enter the highway at a rate that would overwhelm the road’s capacity. Although the idea of having a stoplight might seem to contradict the SAFe concept of continuous movement, the idea of adding work gradually to the system to prevent bottlenecks is fundamental to the SAFe concept.

Meeting solution-level management

The solution-level employees are focused mostly on high-level solution governance. They capture requirements in a larger solution intent, and they work to coordinate several agile release trains around their larger solution train. The following people are part of the solution-level management:

• Solution architect/engineer: These people think about how well the solution maps to the organization’s current architecture. They take a “system view” when they try to match the solution to various technical considerations.
• Solution management: This person works to make sure the solution aligns with the customer’s expectations. They do this by creating a solution vision and roadmap. Then they prioritize the solution on a Kanban board.
• Solution Train Engineer (STE): This person makes sure the agile release trains align with the larger solution train. Each release should incrementally add value to the larger solution.

Using an economic framework to finance a solution

SAFe finances value streams, not projects. You don’t want a focus on a car project; instead you want to finance family transportation. This value stream could have several different solutions (car, minivan, boat, motorcycle). The economic framework is a set of decisions that support this overall view. You’ve already seen how SAFe finances value streams using Lean budgeting (see “Financing value streams with Lean Budgets”) and prioritizing based on the cost of delay (see “Starting the weighted shortest job first”). These ideas come into play in the decisions you make when you’re delivering the best solution.

If you decided to create several family transportation solutions, you’d have to use an economic framework to make the best decisions. You could decide that a minivan would generate the most revenue and so that work would have the highest cost of delay. Using an economic framework, you may decide to make this the highest priority solution.

Planning with solution intent

According to Scaled Agile, Inc., solution intent is “the repository for storing, managing, and communicating the knowledge of current and intended Solution behavior.” It “includes documented, fixed, and variable specifications and designs; reference to applicable standards, system models, functional and nonfunctional tests; and traceability.” In simpler terms, solution intent involves answering two questions:

• What are we building?
• How are we going to build it?

This word “intent,” in this context, means a conscious, willful desire to do something, and it implies that some planning is involved. Think of it in terms of legal language; committing a crime with intent means you did it deliberately, not inadvertently. If you’re an agile aficionado, you may find the concept of solution intent troubling because agile views software development as a continuous process of building an ever-changing product that requires frequent adaptations, not as a process of building a preconceived product. With solution intent, you have the well-established intent with only some flexibility to make changes.

SAFe addresses this concern by splitting the intent into fixed and variable specifications and designs (see Figure 4-11):

• Fixed: Required
• Variable: Flexible and adaptive

For example, suppose a restaurant manager makes the cooks responsible for creating the menu. It’s a hamburger joint, and the manager tells the cooks they need to have six different specialty burgers. The only fixed requirement is that customers will be able to choose any of six different specialty burgers, but it’s up to the cooks to decide what these burgers will be. They can decide based on variables, such as local customer preferences, what they like best to cook, and perhaps which ingredients are in season.

In such a case, the fixed/variable model works well, but what if the restaurant manager makes the six burger types a fixed requirement? In other words, management creates the menu, and the cooks must follow it. The only variable may be the actual recipes — how much of each ingredient to add. Now, the cooks have much less flexibility. If they know, for example, that people are flocking to other restaurants to order, say, an olive burger, they have no flexibility to add that burger to the menu, and the restaurant starts losing business.

If you do decide to use solution intent, be careful how you use fixed and variable design. If you use too much fixed design, you’re probably not getting that much value from your agile teams. If you use too much variable design, you’re probably not getting that much value from your planning efforts.

Prioritizing solutions with a Kanban board and backlog

Like the Portfolio level (and every level in the SAFe framework), the Large Solution level uses a Kanban board. At the Large Solution level, the Kanban board is used to track solutions from the idea phase to completion. After ideas are reviewed, analyzed, and approved, they’re added to the solutions backlog — a prioritized list of solutions that can then be developed and delivered by the solution train, discussed next. (For additional details about Kanban boards, backlogs, and methods used to prioritize work, see the earlier section, “Prioritizing epics and adding them to the backlog.”)

Riding the solution train

The solution train is a coordinated team of teams of teams, along with suppliers, that designs and builds large, complex solutions, such as automobiles, software suites, banking systems, and defense systems. The purpose of the solution train is to produce a solution demo that can be integrated, evaluated, and made accessible to customers and other stakeholders.

Considering the solution from the customer perspective

At the far right of the Large Solution level is the goal of the solution train — to deliver a solution that meets the customer’s need in the context in which the customer will employ that solution:

• Customer: The one and only boss in the system.
• Solution: The products, services, or systems delivered to the customer (internal or external).
• Solution context: The operational environment for the solution, including its requirements, usage, installation, operation, and support. The solution context may be outside of the organization that develops and delivers the solution.

Meeting the program leaders

At the Program level are several leadership roles:

• System architect/engineer: Defines the technical and architectural vision for the solution to be developed.
• Product and solution management: Identifies customer needs, prioritizes features, and develops the program vision and roadmap.
• Release Train Engineer (RTE): Coordinates, coaches, leads, and facilitates the teams that comprise an ART. Think of the RTE as the engineer that drives the train. If you’re familiar with Scrum (see Chapter 6), think of the RTE as a super Scrum Master.
• Business owners: Ensure governance, compliance, and return on investment for each solution an ART develops.

Understanding program increments

The Program level delivers work in a program increment (PI) — a fixed period of time (typically 8 to 12 weeks) a team has to deliver the solution in the form of a working, tested product. If you’re familiar with Scrum, you can think of this as a sprint of sprints. (See Chapter 1 for more about sprints.)

One of the RTE’s most important duties is to manage and facilitate the program-increment-planning meeting. Prior to each PI, the RTE meets with her ART to formulate a plan for completing its work. This meeting may take a couple days, because each ART may have a hundred or more people working in dozens of teams. The RTE must get these teams to coordinate their activities and maintain close communication for the duration of the PI.

Loading work into the backlog

RTEs work with product and solution management to pull epics from the top level and add them to their trains. Together, they use a Program-level Kanban board with columns to help prioritize and organize these epics and indicate what they want to implement now as well as other work that can wait.

Riding the ART through the continuous delivery pipeline

With Kanban board in hand, the RTE coordinates the agile release train (ART). According to Scaled Agile, Inc., an ART is a “cross-functional team-of-agile-teams, which along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length iterations (building blocks) within a program increment (PI) time box.” The idea is to maintain a continuous delivery pipeline with the following four traits:

• Continuous exploration (CE): The process of monitoring market and user needs and figuring out ways to address those needs.
• Continuous integration (CI): The process of developing, testing, integrating, and validating features taken from the program backlog.
• Continuous deployment (CD): The process of taking validated features, building them into the product, testing them, and preparing them for release.
• Release on demand: The process of placing features into production to be released to customers immediately or incrementally as driven by market demand.

The ART is the vehicle that delivers the organization’s value streams (see Figure 4-13). Some value streams are small enough that one ART can deliver its intended solution. Other value streams are large enough that they require several ARTs to deliver a more complicated solution.

These agile release trains also coordinate with larger solution trains. These solution trains deliver a solution demo at the end of every program increment. It’s here that you get customer feedback on the new capabilities of the solution.

The train analogy describes ideal workflow in SAFe product development. The train never stops running. As the cars pass by, the teams pull features from the backlog. Each team completes and delivers its work, where it can be picked up by another team to move it to the next stage in the process. Because the process is continuous, no team has to wait for another team to complete its work. If a team isn’t ready to deliver, it doesn’t hold up progress; it simply waits for the train to pass by again.

You want trains to run without handoffs. (A handoff occurs when one team completes its work and passes it along to another team, so it can begin its work.) Because everyone is always working together on small tasks, you can limit handoffs and move the product through the system more quickly.

Breaking down silos with DevOps

Short for development and operations, DevOps is a mindset and collection of technical practices to improve communication and collaboration among everyone working in the Program level. DevOps consist of the following five elements:

• Automation: Developing and automating the continuous delivery pipeline increases the frequency and quality of deployment, stimulates innovation by making it safer to experiment, reduces time to market, shortens the lead time for fixes, reduces the frequency and severity of release failures, and improves recovery times.
• Culture: Everyone shares the responsibility of delivering value to the customer.
• Lean Flow: The Lean Flow concept has everyone looking for ways to visualize and limit work in progress (WIP), reduce batch sizes, and manage queue lengths to improve efficiency and speed of development and deployment.
• Measurement: DevOps mandates measurement and analysis over intuition in decision-making. Analysis is based on automated collection of real-time data regarding the performance of solutions.
• Recovery: DevOps stresses a proactive approach to recovery, based on the assumption that failures will happen rather than “failure is not an option.” Teams are encouraged to plan for and rehearse failures, to be able to fix forward or roll back (to a prior working state), and swarm to fix a problem whenever one occurs (a stop-the-line mentality).

Transitioning to SAFe can be a monumental challenge for large enterprises with long-established departments for business analysts, project managers, product managers, system architects, hardware and software engineers, and software development, testing, and even deployment.

These separate departments are like vertical stacks that run through your organization (see Figure 4-14). That’s why they’re commonly referred to as “silos.” Silos are tall, thin buildings that farmers use to store grain; they’re designed to keep the stores of grain separate, not to share grain. Likewise, organizations with strict departmental divisions are not geared for close communication and collaboration.

In organizations such as these, creating and coordinating ARTs can be difficult. In a sense, you must create virtual organizations within your larger organization that cut across these silos. As you can imagine, that’s not easy, especially in an organization with a strong control culture. If you’re a manager in one of these silos, then you may feel as though your department and position are being threatened. The purpose of DevOps is to break down silos by creating communities with a shared mission, mindset, and methodologies.

Forming ARTs

Performance at the Program level depends heavily on your team-building ability. The goal is to form teams that can work independently and together to deliver the greatest value to the customer the fastest. Here’s one way to approach the challenge of forming ARTs:

1. List all the teams involved in developing and delivering your product.
2. Divide these teams into different value streams.
3. Create each train so it has the fewest dependencies. You don’t want trains to depend on another to deliver their product. If you do then you’ll just be adding more handoffs.

Think about how this might work in a restaurant. The value stream consists of all the steps necessary to take orders from customers, prepare their orders, and deliver the food and beverages to their table, preferably to everyone who’s sitting at the table at the same time, so they can eat together. That’s three steps: (1) Take orders, (2) prepare food and beverages, and (3) deliver food and beverages.

Now you could create teams around each of those steps, but then you’d have a team of servers to take orders and another team to deliver orders. In addition, you’d have a bottleneck at the kitchen, because they’d be preparing food and pouring drinks. A better approach is to start with the teams and then look at how those teams align with the value stream. For example, most large restaurants have three teams: one for handling the dining room, one for preparing food, and a third for preparing drinks:

• Dining room: Host/hostess, servers, bussers
• Kitchen: Prep cooks, grill cook, broiler cook, fry cook, pastry chef
• Bar: Bartenders

The kitchen team is commonly a team of two or three teams:

• Prep cooks: The prep cooks chop vegetables, make salads, cut and grind meat, weigh and mix ingredients, and deliver uncooked food to the cooks.
• Cooks: The cooks fry, grill, boil, broil, bake, deep fry, and then arrange the food on plates.
• Expediter (Food Train Engineer): Busy restaurants have an expediter who serves as the liaison between the cooks and servers, clarifying and arranging orders as they come in, making sure the food leaving the kitchen matches the order and is up to the restaurant’s standards, ensuring that all orders for any given party are sent out at about the same time, and solving any complaints about the food that they receive from customers via the servers. Having an expediter enables the servers to focus on their customers and the cooks to focus on preparing the food.

Each of the teams functions independently but also must communicate and cooperate with at least one other team: Servers must communicate with the cooks (or the expediter) and bartenders. Cooks must communicate with the servers (or the expediter) and prep cooks. The bartenders must communicate with the servers (and perhaps directly with customers). But you’ve also eliminated a lot of the dependencies. No team should be waiting for the other to start its work. The bartender’s free to make drinks while your cooks are working on meals. When each team delivers its product, it’s scooped up by the wait staff and delivered to the customer. The expediter makes sure all the meals for any given table are sent out from the kitchen at the right time and that the server picks them up to deliver, so nobody at the table has to wait. In SAFe, this is described as the coordination of ARTs.

Taking off from the architectural runway

Near the bottom of the Program level, note that the agile release train runs on top of something called an architectural runway, which, according to Scaled Agile, Inc., contains “the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.”

For example, in a restaurant, while servers, cooks, and bartenders perform the steps required to seat patrons, take orders, and deliver food and beverages, a great deal of infrastructure and equipment is required for them to do their jobs. Infrastructure may include the building itself; a website for advertising and taking orders; a phone system for communicating with customers, suppliers, and staff; a scheduling and payroll system; a system for accepting various methods of payment, and so on. Equipment may include dining room furniture, refrigerators, ovens, grills, deep fryers, plates, silverware, and dishwashers. All of this makes up the architectural runway that supports the restaurant’s efforts to deliver value to its customers. Note, however, that the customers do not receive the value of this architecture directly.

In practice, the architectural runway is built and maintained the same way solutions are developed and delivered to customers — through the efforts of management-directed ARTs. The system or solution architect/engineer, serving as the product owner, helps to define and build out the runway. Typically, one or two ARTs perform most of the work and deliver the architecture as a solution over one or two iterations.

Although the architectural runway is essential for executing solutions, don’t pour time and focus on creating, maintaining, and extending it at the expense of developing and delivering value to customers. You should be spending no more than one or two iterations to implement and prove any new architecture.

Taking a SAFe agile team roll call

The core component of the Team level is the agile team. Each agile team has 5 to 12 members, including members in the following three roles:

• Dev Team: The Dev Team, typically comprised of software developers, testers, and engineers, develops and tests stories, features, or components. These teams are further distinguished with the letters SW, FW, and HW next to their team names to show whether they’re working on software, firmware, and/or hardware solutions.
• Scrum Master: The Scrum Master leads and coaches the team; brings the team up to speed on Scrum, Kanban, SAFe, and Extreme Programming; facilitates the team’s work; fosters a culture of high performance, continuous flow, and relentless improvement; and makes sure that the agile process and SAFe principles and practices are being followed. Scrum Masters also help coordinate efforts among different teams. (For more about Scrum, see Chapter 5.)

• Product owner: The product owner is the team’s content authority and customer representative, essentially serving as quality control to maintain the conceptual and technical integrity of the features and components the team is responsible for delivering. The product owner works with product management (outside of the team) to prepare the team’s backlog and then manages that backlog. She’s also responsible for prioritizing stories and is the only member of the team who has the authority to accept stories as done.

  At the Team level, product owners aren’t true product owners in the sense that they own an enterprise-level product. Instead, they get their high-level guidance from a product manager and then translate their vision into a working product. The product is more like a solution owner; she doesn’t spend time figuring out what to make, but helping the team figure out how to make it.

SAFe generally has two team types: ScrumXP and Kanban, both of which follow the Lean-Agile Mindset and self-organize and deliver their work in predictable chunks:

• ScrumXP: ScrumXP is a hybrid of Scrum and Extreme Programming. Scrum is an approach to software development in which teams of three to nine developers break their work into one- to four-week cycles, called sprints, conduct daily 15-minute progress meetings (standing up), and deliver working software at the end of each sprint. XP stands for Extreme Programming, which features more guidance on software engineering practices. ScrumXP differs from Scrum in other ways, as well:
  • Scrum Masters may handle several teams.
  • An extra sprint for innovation and planning enables teams to shift focus from delivery to come up with new ideas.
  • The product owner maintains the team backlog, which is pulled out of the product manager’s program backlog.
• Kanban: While most teams operate in a Scrum environment, teams also have the option to use Kanban, which helps for visualizing and managing workflow and reducing work in progress. Kanban is a pull system, in which team members pull work from a queue when they have the capacity to do it. This approach may be best for system and maintenance teams. (See Chapter 8 for more about Kanban.)

Defining, building, and testing stories

Agile teams are dedicated to defining, building, and testing stories — small pieces of a product’s functionality as told from the user’s perspective. Pieces are sized so that they can be completed in a single iteration — a fixed period of time that an agile team has to complete its work. Teams engage in the following process to plan, execute, and review iterations:

• Plan: Team members meet to determine how many stories from their backlog they can deliver in the upcoming iteration, and they set their iteration goals.
• Execute: The team develops a high-quality, working, tested system (a program increment) within the allotted iteration time box.
• Review: The team inspects its program increment at the end of the iteration to evaluate progress and adjusts its backlog for the next iteration.
• Retrospective: The team looks back at the results of its iteration, reviews its practices, and considers ways to improve.

The goal is to maintain develop on cadence — a fast, rhythmic development flow that ensures important activities and events occur on a regular, predictable schedule.

Embracing the concept of built-in quality

Built-in quality, one of SAFe’s four core values, is especially important at the Team level, where teams are actually building the solutions. Built-in quality makes everyone on the team responsible for the quality of its piece of the larger product to ensure a fast flow across the entire value stream and to build high-quality solutions. One of the key benefits of built-in quality is that testing is conducted during development instead of at the end of development, so problems can be fixed along the way instead of having numerous problems come to light near the end of a project and having to scramble to fix them.