Chapter 4
IN THIS CHAPTER
Choosing which SAFe configuration fits your organization
Seeing how SAFe aligns your team with management
Mapping your team’s work to solution trains
Focusing on delivering value with agile release trains
Delivering a product with multiple agile teams
The Scaled Agile Framework® (SAFe®) is a modular, scalable system for orchestrating alignment, collaboration, and delivery for large numbers of agile teams. It got its start when Dean Leffingwell and his collaborators (now known as Scaled Agile, Inc.) began looking at how some of the largest organizations deliver software. What they found was a mix of Lean thinking, agile practices, and traditional top-down decision-making. The Scaled Agile team then consolidated and distilled these common practices to form SAFe.
In this chapter, I introduce you to SAFe in principle and in practice. I bring you up to speed on the SAFe framework and principles, offer guidance on how (and how not to) implement SAFe, and step you through the framework’s various management layers so you can determine whether SAFe is the right framework for your organization. If you decide it is, this chapter can help you begin to envision your organization with SAFe and start taking the steps necessary to transform your organization into a SAFe enterprise.
SAFe is a little more prescriptive than other enterprise agile approaches. These practices are often closely related and presented in layers. They start with a few high-level Lean principles and practices for management and then work their way down to the team level. SAFe relies heavily on its infographics. This could be a little overwhelming at first when you look at graphics such as the SAFe full-framework graphic (Full SAFe), shown in Figure 4-1.
Whenever you first encounter a complex model consisting of numerous parts, you can often benefit by stepping back to look at the whole before digging down into the details. In this section, I take you a few steps back to present SAFe in principle and in practice, so you have a general idea of what it is and how it’s used to make large organizations agile.
Here, I introduce the SAFe framework and principles, explain the benefits of its modular approach, and encourage you to view SAFe as a compromise between traditional top-down management and team-based agile. I also steer you clear of the common mistake of focusing too much on SAFe practices without getting a handle on the overarching concepts.
Looking at the Full SAFe graphic (refer to Figure 4-1), you see right away that it’s a beast. It’s designed for hundreds of developers and dozens of teams that are either working on one big product or several smaller products. The product(s) might have millions of lines of code that must be updated regularly across the enterprise. But when you step back for a moment and look at the whole and consider it in the context of the SAFe principles, it all begins to make sense.
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:
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.
When you look at the Full SAFe graphic for the first time, note the following four areas:
The Full SAFe configuration is divided into the following four management levels:
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.
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:
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.
SAFe has nine principles that govern the way everyone in the organization approaches product development:
At first glance, the framework graphic looks like a subway map for the most confusing city on Earth. But fear not. You may not need all four levels of Full SAFe, and you may not use all the little pieces of whichever SAFe configuration you use. The framework tries to show you everything that you can do, not everything you must do. Remember, it’s modular.
The first choice you need to make is which SAFe configuration to use. Each of these configurations includes only the management levels that are appropriate for that solution. Four are provided:
SAFe’s flexibility and it numerous options make it a popular starting point for organizations interested in making the leap to enterprise agility, but those qualities also pose a challenge — it’s easy to get lost in the process and lose any sense of the ground below.
The Agile Manifesto (see Chapter 1) was a battle cry against large processes and heavy systems. In fact, the very first value in the Agile Manifesto is “individuals and interactions over processes and tools.” Teams are supposed to focus on delivering software, not on the overwhelming process of doing so. Looking at the SAFe diagram, you’d have a hard time imagining the founding agile workgroup accepting this framework as part of the agile mindset. It’s an overwhelming process filled with dozens of tools.
Many people in the agile community feel that SAFe subverts the benefits of being agile. The framework takes away much of the self-directed power of agile teams. It does this in favor of giving management greater visibility and control. In a sense, SAFe takes the agile teams that were designed to own all the aspects of the product and forces them to align with a larger organizational goal.
In theory, SAFe may contradict agile, but as I explain in the following sections, it’s more of a compromise that makes sense in terms of a large-scale enterprise product.
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.
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.
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.
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.
If you’ve worked on a large enterprise project, then you’ve probably heard of the waterfall approach. In 1970, Dr. Winston Royce described a method for “managing large software developments” based on his personal experience in the development of ground systems for spacecraft mission planning, control, and post-flight analysis. The approach, as he described it, is delivered in seven sequential phases (including analysis and coding), cascading like a waterfall from system requirements to operations. Royce introduced five additional process features or steps “to eliminate most of the development risks.” Interestingly, the fifth step Royce added was to “involve the customer” in a number of reviews at critical phases in the waterfall sequence.
Take automobile manufacturing as an example. To develop a new vehicle, you would first envision the type of car you want, such as an SUV hybrid with all the trimmings. Designers would draw the car, then engineers would figure out which parts were needed and how to fit them all together, then analysts would determine how to build it and how much that would cost. After it’s built, experts would test the car for safety, drivability, and so on. Based on the test results, you would probably need to go through the process several times until you had the product you wanted. Finally, you’d sell the completed product to dealers who would sell it to their customers.
Royce applied this approach to software development. He said to create software you needed to plan out all the features. Then, high-level software architects would create a design for the whole product. Then teams of software developers would work to code the product. A quality assurance group would test-drive the software, bugs would be fixed, and then you’d ship the completed software to your customer.
In this section, I explain the fundamental flaw in this approach to product development, particularly software development, and explain why combining the waterfall approach with agile, a common practice, can be a recipe for disaster, if it’s not done right.
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.
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.
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?
At its heart, enterprise agile is a radical change; it’s a difficult change to embark on, and it’s even more difficult to see through to its finish. SAFe offers organizations the comfort of having a structured plan for their transformation, but it doesn’t confuse this plan with the groundwork required for transformational change. Such change requires that people think about their work in a different way, so don’t fall into the false comfort of the promise of a structured plan.
An old joke keeps floating around the Internet: If you want to look smart at meetings you should ask, “How do we bring this idea to scale?” “Scale” has become a corporate buzzword. No one really knows what it means. Does it mean you want to make something bigger? Or does it mean you just want something to be more widely used?
This lack of understanding only makes companies think wrongly that they need to use scaling to tackle many of their challenges. The fact is, the Scaled Agile Framework has benefited from including these buzzwords. It has both “scale” and “agile” in its name, so it seems like a ready-made, pre-packaged solution for any large company. It lends itself well to marketing; if you’re a large organization, and you want to try agile, then you’ll need the Scaled Agile Framework.
Before you embrace SAFe, ask yourself whether it makes sense for your organization. If you have only 25 people in charge of developing and delivering new solutions, SAFe probably isn’t the right solution. You can figure that out just by looking at the SAFe graphic. Skim down the left side of the graphic, and you’ll see a lot of new roles: Epic Owners, an Enterprise Architect, Lean Portfolio Managers, Solution Architects and Managers, System Architects, Product Managers, Product Owners, Scrum Masters, and more. Start adding all that management to a small group of people, and just imagine what will happen. Your organization will have more managers than developers.
The Full SAFe configuration graphic (see Figure 4-1) has four management levels and an underlying layer, the foundation layer, on which those levels rest. In this section, I guide you through the foundation and the four management levels and provide some guidance on how to put the framework into practice.
At the bottom of the Full SAFe graphic is a gray box that represents the foundation on which the framework rests (see Figure 4-2). A line extends from the left and right sides of the box to surround the four management levels, indicating that the foundation layer applies to all four levels and to the entire enterprise. The foundation contains the following items:
In one respect, the enterprise is the entire organization; it encompasses executive leadership and all four process management levels. In another respect, it sits at the top of the SAFe food chain as the source of all the business strategy, funding, and overall governance of the organization.
SAFe takes a practical view of the enterprise — as the entity that hires people who provide their expertise or service to the organization. The relationship is very transactional. The enterprise provides employees with a salary, and, in return, they execute the enterprise’s strategic themes and product delivery.
In its role as the head of the organization, the enterprise works with others in the organization to develop strategic themes that the rest of the organization is then responsible for executing. Execution begins at the Portfolio level, discussed next.
As the head of the organization, the enterprise collaborates with top-level managers at the Portfolio level (see Figure 4-4), where managers much reach a consensus on many of the decisions around a product. At this level, management sets the direction for the entire enterprise by creating value streams that align with the enterprise’s strategic themes.
In this section, I take you on a tour of the Portfolio level, where you meet the people who drive the process and develop an understanding of the purpose of this level and how it functions.
The Portfolio level includes three distinct roles (which can be held by several people):
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.
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.
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.
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.
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.”
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:
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:
Finding what customers value can be easy or difficult, depending on how your organization creates its product. For example, if your company sells running shoes online, then determining what customers value should be pretty easy; they want quality shoes at a reasonable price that are easy to find and order, are delivered quickly, and are free and easy to return if they don’t fit. However, if your company develops an accounting application, finding out what the customer values can be more difficult. You may even have several different customer types — home users, small-business users, and corporate accounts.
Having a conversation early on about what the customer values is a key benefit to using SAFe. The portfolio-level practices encourage executives to help the rest the organization define what high-level value they need to provide to their customers. The SAFe enterprise strategic themes get the ball rolling, then the managers have to turn these themes into actual value streams with dedicated budgets.
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:
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.
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.
If you’re a large organization, you may have several teams of teams that must be coordinated to deliver large solutions. SAFe accommodates such scenarios with its Large Solution level (see Figure 4-10).
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:
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.
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:
SAFe addresses this concern by splitting the intent into fixed and variable specifications and designs (see Figure 4-11):
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.
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.”)
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.
The solution demo is the product of the solution train’s collective efforts. After it’s produced, the solution demo can then be inspected by customers and other stakeholders and adapted.
The solution train’s focus is on building and integrating features and capabilities into the solution:
An enabler is supporting architecture or infrastructure that’s not part of the value delivered to the customer, but is required to provide that value. For example, you may need a new server, a new testing environment, or a network upgrade to deliver value to the customer. All these items would be considered enablers.
Suppliers are organizations (internal or external) that provide components, subsystems, or services to support the solution train’s ability to develop and deliver solutions to customers. Suppliers are often used to reduce lead times and improve quality.
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:
The Program level (see Figure 4-12) is like the factory floor; it’s where most of your teams and teams of teams (ARTs) work to develop and deliver the product. In this section, I introduce you to the various components that comprise the SAFe Program level and provide guidance on how to establish a Program level in your enterprise.
At the Program level are several leadership roles:
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.
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.
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:
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.
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.
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:
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.
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:
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:
The kitchen team is commonly a team of two or three teams:
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.
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.
At the very bottom of the SAFe graphic is the Team level (see Figure 4-15), where the division of levels begins to blur. The Team level is actually an integral part of the Program level, because an agile release train at the Program level consists of teams. If you think about the Program and Team levels as two separate levels, then you might think a handoff must occur between the two levels, which is not the case. It’s not as if the teams are feeding their work into the continuous delivery pipeline; they’re performing their work inside the continuous delivery pipeline.
In this section, I take you on a tour of the Team level, so you get to meet the people who work there and find out more about how they do their jobs.
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:
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:
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:
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.
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.
The SAFe spanning palette (see Figure 4-16) contains a collection of tools you can use regardless of the level on which you’re operating:
It seems like everyone is running marathons. Every time I open up LinkedIn or Facebook, I see a picture of someone I know running a marathon. I had to know how these people got to this level of athleticism. I finally asked a runner I know, “How do you get to be a marathoner?” He looked at me and said, “I run a lot.” I didn’t expect such a simple answer.
The same can be said of the process of making an organization agile. The framework is generous about what a SAFe organization should look like. It has levels on top of levels, dozens of roles, and relationships between those levels and the roles. Yet the framework is stingy about what to do to make it work. You know where you need to be, but the system is not very clear about how to get there. And when you ask for clarification, SAFe’s answers aren’t very helpful:
You could easily forgive this missing information if SAFe were a lightweight framework like Scrum. Scrum has only three roles, three artifacts, and a few events. You’re expected to figure out a lot on your own. However, with a large system, such as SAFe, you need more guidance.
In this section, I plug the gaps by providing guidance on how to transition your organization to SAFe, and I help you steer clear of the most common pitfalls.
Choose several people in the organization and get them trained as SAFe program consultants. Eventually, you must train everyone in your organization, so all of them understand SAFe in principle and practice, but getting several people trained early on is a good start.
Give it more time. When a person is trained as a SAFe program consultant he has a week to make the transition. The reality is that most organizations will need much more time laying the groundwork for such a big change.
Start your training by introducing the following three key concepts (in this order):
If you can get your organization to understand these key concepts, rolling out the framework will be much easier.
SAFe is an attempt to fit agile into your organization, so the framework will feel as comfortable as an old pair of jeans. However, this can be a false sense of comfort that carries its own risks. It often seduces companies into embracing a water-agile-fall approach, which allows them to maintain a control culture they’re reluctant to relinquish and simply adopt agile for a smattering of teams within the organization. For reasons given earlier in this chapter, in the section “Avoiding water-agile-fall,” you won’t reap the full benefits of agile by following this approach. Instead, you must make your organization agile.
To make your organization agile, you need to change its collective mindset, its culture, and you must break down the silos of clearly defined departments. Everyone in the organization needs to stop thinking so much about product and think more about process, and stop focusing so much on projects and shift his focus to value streams.
A great way to maintain a SAFe mindset and culture is to start communities of practice (CoPs) within your organization. A community of practice is an informal self-organized group of people who share a common interest, typically in a specific technical or business area. The group meets regularly to collaborate, share information and insight, improve members’ skills, and continuously advance their collective knowledge of their area of expertise. In other words, they “talk shop.”
The good news is that in large organizations, such groups are likely to exist in various departments. For example, an organization is likely to have separate departments for software development, engineering, business analytics, information technology, accounting, and so forth. While these divisions may be challenged by the need to create agile teams, communities of practice enable and even encourage the divisions to persist.
However, CoPs need not be departmental. Sometimes developers create CoPs around a certain skill, such as Java development or programming in Python. They may even create a CoP around agile practices such as Extreme Programming or user stories.
While the primary goal of CoPs is to increase knowledge and skills in an area of expertise, a beneficial byproduct is that the groups can share their knowledge and experience of working in teams. In the process, their discussions can deepen their understanding and appreciation of SAFe and strengthen the SAFe mindset and culture.
As soon as you begin to form your agile teams and ARTs, start to encourage and facilitate the creation of CoPs. As soon as people in your organization receive their SAFe training and find out about CoPs, they’re likely to take the initiative to start these groups on their own. A large part of encouraging them is to simply get out of their way. Let them schedule and manage their meetings. You can also encourage the formation of CoPs by allotting time during the normal day to conduct the meetings and perhaps by budgeting for snacks and beverages.
Don’t be too concerned if a few of your CoPs fizzle out over time. They tend to have a natural lifespan that gives out when the need for them no longer exists (see Figure 4-17). Do be concerned if all your CoPs suddenly stop meeting. That usually means the people are spending too much time doing and not enough time learning.