SAFe in a Nutshell – The Simplest Way to Understand SAFe

SAFe is the most popular framework in use today to guide an organization’s efforts to scale agile practices beyond the team level. But, when people look into it for the first time, this is what they usually see:

Once you’ve received solid training and guidance, the SAFe “Big Picture” becomes a beautiful thing. But, without those necessary supports, there’s no doubt that it’s an overwhelming image. It intimidates some, which may make them hold off on implementing their scaling plans, even if they’re otherwise ready.

To counteract this, we want to present a simple way to understand how SAFe works at its core. To do so, we’ll start with a framework millions of people — hopefully, you included — are already familiar and comfortable with: Scrum.

Check out this in-depth video for a visualization of SAFe scaling up from Scrum:

The Core Elements of Scrum

Scrum is a time-tested, commonly used method for small agile teams to structure their work. It provides for three specific roles, some routinely practiced ceremonies, and just a few important principles that keep the workflow agile instead of letting it get bogged down in bureaucracy.

Scrum overview

1. Scrum Teams – high-performing, autonomous, self-organizing, and self-managing groups of five to nine individuals who develop synergy by routinely working together on the same or closely related work in a highly collaborative environment.
2. Timeboxing and Sprints – Scrum work is completed within distinct time periods (aka timeboxes) of two to four weeks, called a sprint (SAFe refers to it as an iteration). The two-week sprint is most common, so we’ll use that for illustration throughout this article.
3. Sprint cadence – Within each sprint, there are prescribed ceremonies that happen at the same time each sprint and therefore, form a cadence that can be pre-scheduled and planned for sprint after sprint. In general, you can always count on the ceremonies happening at the same time for a given team. These ceremonies are outlined below.
4. User Stories – Scrum work is generally presented as User Stories, which are maintained and prioritized in the team backlog. Stories are the smallest bundle of tasks that achieves a measurable result or business goal. Ideally, no story will be left unfinished at the close of a sprint.
5. Story Points and Velocity – Teams size stories using relative estimation (planning poker is the most common technique) and assign points to the stories to represent the relative amount of the team’s capacity would be used to implement the story. The total number of story points that a team has demonstrated that they can finish in a sprint is known as the team’s velocity and is used to inform how much work a team can take on and commit to within a sprint.

Scrum roles

1. Product Owner – The Product Owner is responsible for choosing and prioritizing which user stories the team will work on during each sprint. They’re also responsible for deciding on each story’s definition of done, and either accepting or rejecting stories turned in by the team based on that measurement. They fill the role of Content Authority, meaning they handle “what the team works on”.
2. Scrum Master – The Scrum Master is responsible for making sure the Scrum process is being followed consistently, and that team members have what they need to effectively do the work. They fill the role of Execution Authority, meaning they handle “how the team can execute the work better”.
3. Team Members – The team members are cross-functional experts in the skills needed to accomplish the work, and their experience allows them to self-organize and manage the work. They fill the role of Technical Authority, meaning they handle “the right way to get the work done.”

Scrum ceremonies

1. Sprint Planning – a meeting that occurs on the first day of each sprint. The team gets together to discuss the goal(s) of the Sprint, the stories being pulled from the backlog to satisfy that goal and review dependencies, risks, etc. Many teams also break stories down into tasks and assign time estimates to them. When they are satisfied that they have sufficient work identified (no more than their demonstrated velocity), they commit to completing a selection of stories by the close of the current sprint.
2. Daily Scrum (aka Standup) – a brief synchronization meeting held each morning of the sprint. The team discusses what work was accomplished yesterday, what they plan to accomplish today, and anything that stands in the way of accomplishing what they have planned.
3. Backlog Refinement – while this isn’t an “official” Scrum ceremony, many teams schedule this on a cadence as well. This is where the team reviews and sizes User Stories targeted for the next sprint.
4. Sprint Review – a meeting held on the last day of each sprint, during which the team demos finished work and discusses metrics to evaluate the success of the sprint.
5. Sprint Retrospective – also held on the last day of the sprint, this is a review of the process itself: what went well during the sprint, what could have gone better, and any suggestions for improvement in the workflow going forward.

Most organizations that practice agile use Scrum or a very similar hybrid version of it. It always works well in smaller companies with just one, two, or a handful of teams. As these organizations grow, though, they find the higher number of teams starts to complicate things. There are more inter-team dependencies, communication and collaboration become more challenging, and the process starts bogging down.

That’s where scaling agile becomes necessary. And, although using the SAFe framework may look like it’s adding even more complexity, there’s a simple, elegant way to envision your agile practices scaled across the entire enterprise:

Scaling up Scrum

As you apply SAFe to your workflow, the simplest way to understand it is to recognize how each level correlates to the level below.

Scrum, as it’s described above, makes up the bottom level of SAFe: the Agile Team. Moving up one level, we arrive at the Program:

Program principles

All the Scrum principles still apply here, although some of the terminology needs to change.

1. A team of teams – to maintain agility at the program level, a team of teams is developed. This is known as the Agile Release Train (ART), and it normally consists of 5-12 agile teams (or roughly 50-125 people) working together to develop the same or closely related features towards a common vision.
2. Timeboxing, iteration, and cadence – program work is also completed within timeboxes, but they need to cover a longer period. This is called a Program Increment (PI), and it consists of five full iterations (sprints) — 10 weeks by default. Just like agile teams, the ART has a set of ceremonies that happen on a predetermined cadence throughout the PI.
3. Features – program work is still maintained and prioritized in the program backlog. But, instead of stories, you’re concerned with features. Each feature will be decomposed into multiple user stories as work is assigned to various teams. Ideally, no feature will be left unfinished at the close of a PI. Like stories, Features are also sized using story points that are normalized across the teams on the train so that a story point represents approximately the same amount of capacity consumed for each team.

Program roles

Understandably, accomplishing all this will require different titles with different scopes of responsibility, but the roles they fill are familiar:

1. Product Manager (PM) – The Product Manager is responsible for choosing and prioritizing which features the ART will work on during each PI. They fill the role of Content Authority, as the Product Owner (PO) does at the team level, and one PM can support several POs. The key difference is that the Product Owner needs to be there for the team on a day-to-day basis while staying aware of larger business initiatives. The Product Manager focuses exclusively on the business goals.
2. Release Train Engineer (RTE) – The RTE serves the same role as each team’s Scrum Master, making sure agile processes are being followed consistently, and that the team of teams is functioning efficiently. They also help remove impediments that the teams cannot remove themselves. They fill the role of Execution Authority at the program level.
3. System Architect – There’s value in maintaining Technical Authority at this level as well, to establish technical guard rails and drive the establishment of an architecture runway with which the teams can apply emergent design concepts to evolve their design incrementally within the guard rails. The System Architect fills this role.
4. Business Owner – This is the only new role at the program level with no direct equivalent on a team. This is a stakeholder (or small group of stakeholders) with ultimate responsibility for the business outcomes from each ART. As such, they have an active role in many of the ceremonies and serve as primary liaison between the PM and executives.

Program ceremonies

The ceremonies used at the program level are similarly altered but accomplish the same purposes.

1. PI Planning – This ceremony scales up the concept of sprint planning. PI planning is a 2-day meeting held near the end of the last iteration of each PI, known as the IP iteration (for Innovation and Planning). There, the ART gets together to discuss the features being pulled from the backlog for the upcoming PI and create plans, at the user story level, how to implement those features. Stories at this point are not considered “sprint ready” but are defined enough to plan at this higher level of detail. The outcome of the PI planning session is a set of objectives that summarize what each team as well as the ART collectively will accomplish within the PI as well as a plan to get there, captured on the Program Board. As such, they are analogous to the concept of a sprint goal.
2. Scrum of scrums – This ceremony scales up the concept of the daily scrum. While a daily standup with all the team members present would be impractical at this level, a meeting is held once or twice a week, allowing representatives from each team (usually the Scrum Master) to answer the same basic operational questions, focusing on the cross-team dependencies and impediments. In this way, all the teams stay in sync.
3. PO Sync – This ceremony scales up the concept of backlog refinement. While some parts of this meeting may be focused on clarifying the current PI scope, it’s main purpose is to focus on the future PIs in terms of features and roadmap to prepare for the next and subsequent PIs.
4. Inspect and Adapt Workshop – This ceremony scales up the concept of both the sprint review and the sprint retrospective. It contains three parts, the PI System Demo, Quantitative Measurement, and the Problem Solving Workshop. The first two parts correspond to the sprint review and the third corresponds to the retrospective. This meeting is held within the IP iteration just prior to the PI planning session for the next PI. During the PI System demo, the ART demonstrates the features that were completed within the PI to the key stakeholders and receive feedback from the same. The success measures for the PI are reviewed in the second part, and the ART does a deep root cause analysis on one or more problems that affected many teams on the ART within the PI and therefore helps the ART operate more effectively moving forward.

Scaling From Program to the Large Solution

As you might have guessed, taking everything up another notch to the large solution level involves much of the same. This level is only used for organizations who are building really large systems that requires the collaboration and alignment of multiple ARTs.

Solution principles

All the same principles still apply, but once again, the terminology evolves.

1. The ART becomes a Solution Train comprised of 3-10 ARTs.
2. The Solution Backlog is made up of capabilities, which are then decomposed into features.
3. Solution Trains run on the same PI cadence as the ARTs that comprise them.

Solution roles

Again, each of the three roles appear at the solution level.

1. Solution Manager – the scaled-up product manager, Content Authority of the solution who owns capabilities on the Solution Backlog.
2. Solution Train Engineer – the scaled-up RTE, Execution Authority of the Solution Train.
3. Solution Architect – the scaled-up system architect, Technical Authority of the Solution Train.

Solution ceremonies

Solution stakeholders will generally attend a portion of the program level ceremonies for ARTs under their purview. In addition, they also facilitate pre- and post-PI meetings designed to synchronize the inputs and outputs of the individual PI planning sessions for each ART.

1. Pre-PI – an opportunity to align PI planning for all ARTs and address potential blockers across the Solution train. Agreed to capabilities and corresponding ART features are the key outputs.
2. Post-PI – an opportunity to review the output of each PI planning session and make any required adjustments to the capabilities that had been planning during the pre meeting

Scaling From Solution to Portfolio

At the highest level, known as Portfolio, strategy and high-level operations are centralized. Things look a little bit different here because, at this level, it’s no longer about doing the work. Here, the focus is on why the work needs to be done — the business goals everyone is working together to achieve.

Still, similarities remain.

For instance, the Enterprise Architect serves as Technical Authority at the portfolio level, serving much the same purpose as the Solution Architect. Since this level has no direct connection to the work itself, Execution Authority is not required and there is no direct equivalent of the RTE or STE here however, the Agile PMO and Lean Agile Center of Excellence (LACE) collaborate with the SMs, RTEs, and STEs to achieve the required executions support.

A portfolio backlog exists, comprised of epics that will be decomposed into capabilities. These large-scale initiatives have no set timebox and will often span multiple PIs. So, work is usually managed on a Kanban board for workflow visualization and adaptation. Epic Owners act as the champion for the epic to guide it through the kanban process, but they are not considered the Content Authority. Instead, the Portfolio Management and Business Owners that operate at the Portfolio level are collectively considered the true Content Authority.

Conclusion

While the concept of Scaling Scrum is a useful way to think about the various levels of SAFe, it should be noted that other Lean-Agile concepts like Systems Thinking and Organizing Around Value Streams also play a huge role within the framework and should be well-understood to understand the framework. That said, by always asking yourself “what would a team using Scrum do” is often a useful question to ask yourself as you are thinking about the operation of the levels above the team since many of those same scrum concepts are scaled as outlined here.

How to Dive Deeper

We’re going to be publishing a series of blogs soon that will dive deeper into each of the key roles — Content Authority, Technical Authority, and Execution Authority — across all four levels of the SAFe 5.0 framework.

However, if you’d like more specialized training or consultation, we encourage you to explore our SAFe services and get in touch with any questions.