Cracking the SAFe: An expert's take on the Scaled Agile Framework

When TechBeacon asked me to write an article on SAFe, I was very excited. SAFe, or the Scaled Agile Framework, is for large-scale software development teams of 50-125 people who are on a program of multiple projects but want to still embrace the best parts of agile, despite their team's large size.

I work for Blue Agility, one of only nine SAFe partners at their highest partnership level: Gold SAFe Program Consultant Trainer (SPCT). We're committed to helping organizations adopt SAFe. Though I'm a relatively new kid on the block, having just joined them in February of 2015, my 15 years of iterative, Rational Unified Process (RUP), scrum, and Disciplined Agile Delivery (DAD) experience allow me to see many things that my SAFe-certified peers don't always recognize.

I like SAFe for many reasons. As with any framework, there are definitely parts I'm not fond of, but its strengths far outweigh any of those pesky areas, and by bringing in best practices from other tool kits, SAFe works perfectly for my large teams.

My favorite feature in SAFe is the main diagram itself. Second would be the easily memorized URL: www.scaledagileframework.com. This means that anytime you need a reminder, want to have a discussion, or need to settle a debate, it's quite easy to check the diagram. And every icon is clickable to give you the details you need to further your understanding and possibly make a decision.

Yet, there are some features of SAFe that aren't intuitive. In this article, I want to introduce you to SAFe in a way that simply navigating the site can't. My new teams struggle with SAFe's unusual and unique terms, and they don't always immediately see the patterns that permeate the model and (if you understand them) make it easier to adopt and understand. Teams who are new to SAFe aren't even sure what problem it solves or what problems it doesn't address. I'll explain that as well. Finally, I'll give you both the traditional way to get started and the bold way that I encourage my teams to adopt.

What problem does SAFe address?

The focus of SAFe is to manage large-scale programs in an agile manner. Because different companies use the word "program" differently, let's make sure our definitions are clear first.

1. Project: Most people know what a project is, but struggle to define it. Go ahead, give it a try. It's tougher than you might imagine. Here's what's important: A project is bigger than a simple change request; it takes a full team to accomplish, not an individual effort; it needs a manager to plan and track the project to completion; a project typically take a few months to a few years; and a project is a temporary thing.
2. Agile team (aka whole team): A stable, dedicated set of people who have all the skills needed to execute a project. Agile has a goal of two to nine people on a team—two is debatable, but one is, without a doubt, not a team. So I use two as the minimum size for an agile team. Ideally, a project consists of one team. However, often the team is either bigger than nine people, or has a "core team" of nine or fewer but requires additional people to make the team "whole." Sometimes the teams are much bigger than nine, and they start breaking into multiple "sub teams."
3. Program: A program is a collection of projects that are functionally related.
4. Portfolio: A software portfolio is also a collection of projects. But in this case they're fiscally related, sharing a budget or resources. Portfolio management is about deciding which projects to staff and should ideally be based on maximizing ROI.

Standard scrum targets small teams. SAFe takes the patterns of scrum and expands them to work for programs. It also has some patterns for portfolio management as well.

What does SAFe not address?

Team size is just one of many complicating factors a team can face. But there are other complexities that SAFe doesn't address at all, and others that it only partially addresses. Where can you go to learn about these other factors? One good source is Scott Ambler's Agile Scaling Model, which I had the pleasure to be involved with even before it got its final name.

Scott's initial Agile Scaling Model described three levels of increasing complexity. He suggested that a company could have many projects in flight, operating at any of these three levels. A team should select the level that best matches their complexities, rather than having a single, one-size-fits-all flavor of agile that fails to provide the right level of guidance to teams at the other two levels of complexity.

The highest level of complexity is called Agility@Scale (A@S); the middle level is his well-known Disciplined Agile Delivery (DAD); and at the lowest level of complexity is what he calls Core Agile, which is basically scrum. At the A@S level, Ambler describes eight complexity factors. SAFe nicely handles team size and enterprise discipline and has some decent content for technical complexity, but it doesn't provide any guidance for a few of the other A@S factors—specifically, geographical distribution, organizational complexity, compliance requirement, domain complexity, and organizational distribution. So you shouldn't look to SAFe alone to solve these team complexity factors. Scott's model has evolved since my involvement, but his idea of cataloging a team's complexities and having reusable patterns with which to solve them is a cornerstone of the Agile Scaling Model.

Introducing the SAFe Rosetta Stone: What do those odd terms really mean?

When you look at the top-level diagram for SAFe, there are a number of terms that aren't immediately clear. But use my handy translation tables below and the model will start making sense.

*"Deliver on cadence, release on demand" is one of the more exciting features of SAFe. It advocates that we keep both a scrum team-level rhythm and a program-level rhythm to deliver on cadence, but that release should be possible at any time, not just at a program increment boundary.

Here are the typical scrum team roles at the three SAFe levels:

** SAFe doesn't call out the pattern as clearly at the portfolio level. I add these two roles to carry the pattern and because it works very well for my clients, even if they aren't using SAFe.

Here are the typical scrum ceremonies at the SAFe program level:

The above three tables should make deciphering the SAFe top-level diagram much faster and easier for you.

How do you get started?

The most common and recommended approach is to start at the program level of SAFe. Program-level management is identified and trained. Then SAFe teams are created, trained, and the first release planning event is held in a dynamic and exciting face-to-face ceremony. My first one had over 150 people and the energy level was incredible. Every individual contributed, which was impressive with that volume of people.

A less common approach is to start at the portfolio level. However, possibly because portfolio management is my passion, I like starting at the portfolio level. Here's my high-level list of steps:

1. Identify your portfolio owner. That's the person on the hook to ensure ROI for the organization.

2. Understand the business strategy, enterprise business drivers, and the business unit budgets.

3. Identify the strategic themes for the portfolio.

These three steps are easy in some organizations and quite challenging in others. Some are able to adopt SAFe without worrying about these three steps and come back to them later. Either way, the next steps are where it gets exciting, and it's perfectly fine to start here, at number 4:

4. Identify your value streams (product lines) and allocate their budgets.

5. Identify your agile release trains (ARTs). These are the dedicated product line teams. For many organizations this is a nearly impossible feat. For those situations, I recommend looking at some of the other resource allocation approaches in portfolio management and blending them to successfully get your ARTs launched.

6. Identify your release train engineers (RTEs). They are basically program-level scrum masters.

7. Create your initial epic (project) backlog. I've seen clients really struggle here. Keep it simple—you probably already have a pipeline of projects. Simply treat those as your epics and you should be good to go.

8. Identify the other program-level roles. See the table above for who they are (or the SAFe website).

9. Identify your ART teams and team members.

10. Start pulling epics from the backlog!

11. Craft features from the epics. Remember that these are "side of the box" features, not detailed DoD features. Think "Buy a book," not "The system shall allow credit card purchases."

12. Derive stories from the features. I like using scenario-driven development for this step over the typical brainstorming techniques I usually see recommended.

13. Schedule your first face-to-face release planning session and you're off to the races.

One last thought on how to get started: I've noticed that many companies adopt SAFe as their first flavor of agile. In my opinion, if they can adopt basic scrum techniques first, their odds of successfully applying SAFe go way up. With strong coaches you can move straight to SAFe, but the road will be a bit more bumpy.

Go try it

SAFe is a fantastic tool for managing large-scale programs consisting of multiple teams working on large epics. It doesn't address some complexities, such as geographical distribution and compliance requirements, and SAFe has some unusual terms. But the terms map to common-sense ideas and its language is easy to adopt. The patterns of a basic scrum team roll up into the program level and somewhat to the portfolio level. Most organizations adopt SAFe by starting at the program level, but I prefer starting at the portfolio level, if possible. I often use additional portfolio practices to supplement the SAFe practices at that level. Teams that have already mastered scrum have an easier time adopting SAFe.

SAFe's top-level diagram is incredibly elegant and shows every nook and cranny of a robust framework. There are some ideas that bother me in SAFe, and I always adjust them for my teams, but the overall framework is strong, well planned, and fairly easy to follow.

Keep learning

• Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.

• Put performance engineering into practice with these top 10 performance engineering techniques that work.

• Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.

• Discover best practices for reducing software defects with TechBeacon's Guide. 

• Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.