Using SAFe to Improve Quality and Add Business Value

The Scaled Agile Framework, or SAFe, is a popular brand of agile in use by many firms, and it has a significant trajectory. SAFe is a strategy for not only making the team agile, but also making the enterprise agile. It provides a framework in the form of an agile program that includes roles, teams, processes, meetings, and actions for the enterprise agile program.

One of the many things I like about SAFe is that its foundation is in lean development and support for DevOps. Lean software development principles make SAFe more effective in helping you deliver quality software.

The SAFe model is divided into three parts or levels: the team level, the program level, and the portfolio level. Each of the levels has its own artifacts, ceremonies, and roles, as shown in figure 1. The bulk of where SAFe’s thought leadership extends is in the program level and the portfolio level. The levels are virtual and do not necessarily directly correspond to departments of any firm. 

Let’s take a look at SAFe’s team level. It is certainly aligned with SAFe, but it very closely resembles the community base agile structure. The team level has all the base agile roles, artifacts, sprints, planning, and meetings. SAFe does add some layers to the traditional base agile in that multiple teams work at the same time on a cadence. Each team builds different layers, or components of the software product or software system. Additionally, each team is aligned with a team-level product owner and a ScrumMaster.

Instead of a product backlog, SAFe has a team backlog. The team backlog is the product backlog, but with an emphasis on the idea that team backlog items have no firm team implementation commitment. Just like the product backlog feeds the sprint backlog in base agile, the team backlog feeds the sprint backlogs. In SAFe, the stories in the sprint backlogs are committed to by the teams.

Also, just like a base agile sprint results in the team releasing a product increment, the SAFe team releases a program increment (PI) made up of all teams’ work product. The PI is a fully integrated, multilayer or multicomponent, part of the eventual software product or software system.

Conceptually, the product increment and the SAFe program increment are identical. However, the PI has multiple tiers. In SAFe, the PI integration strategy is determined by the SAFe system team. The system team also continually tests the PI. The PI is designed for continuous feedback, continuous testing, the best management of change, and the truncation of incorrect business or technical strategy.

By default, the SAFe teams develop the PI in a cadence for five sprints. The cadence is focused on up to five sprints where the fully integrated PI is developed and tested. This development and team cadence is managed by the SAFe program level. The SAFe development teams building the PI is called the SAFe agile release train (ART). The ART and the SAFe program are synonymous. All the SAFe team-level teams are part of the ART, and the goal of the ART is the PI.

The SAFe program level has its own roles, teams, artifacts, and meetings. This level supports the ART and the teams on the ART. The ART is facilitated by a role called the release train engineer, who can be described as the program-level ScrumMaster, similar to the program ScrumMaster in a Scrum of Scrums.

Other roles at the SAFe program level include the system architect and user experience (UX) lead. These roles support the ART by providing application architecture. For example, the system architect would specify certain app servers or databases, while the UX lead would design the end-user experience and make sure it is a common user experience.

As the ART proceeds, there are early system-level demos at the program level that involve reviewing the integrated PI. These system demos are coordinated and scheduled around team-level demos. The current version of SAFe no longer includes specific harden activities. Hardening now takes places continuously throughout the sprints.

In each running of the ART, the last sprint is the innovation and release planning meeting for the next set of five sprints. This sprint is a major meeting where the whole program meets in person and plans the next ART. It is quite an undertaking, but SAFe provides sample agendas to make the release planning sprint as efficient as possible.

The program level’s working product is the PI. The PI is also driven by a backlog artifact, the program backlog. This backlog contains business features, as only features are discussed at the program level.

Just as the team sprints are driven by the sprint backlogs, the PI is driven by the program backlog. The SAFe program level has demos, releases, and backlogs just like the team level. The program also builds this work on top of an architectural runway, which maintains a common enterprise architecture. The role of release train engineer is analogous to the team-level ScrumMaster, and the product manager role is analogous to the team level’s product owner. The product manager owns the team backlog and represents the business at the program level.

The program level has a number of teams that support the ART. Among these teams are the system team, the DevOps team, and the business owners. The system team supports the program and team levels with tools and processes for configuration management and continuous testing for the PI. The DevOps team supports the program and team levels with tools and processes for continuous integration and continuous delivery. The business owners represent managers and senior stakeholders and approve the ART objectives. They also evaluate the released PI against those objectives.

Together, these teams make it possible to increase product quality and accelerate business value. The teams enable the agile best practices that help to realize business value sooner and to discover problems earlier in the process when it is less expensive to take corrective action. Ultimately, these practices ensure a PI that supports the business and its customers, and the teams provide the ART flexibility to release on demand if the business environment calls for it.

Supporting the program and team levels is the SAFe portfolio level. The portfolio level essentially funds the program and team levels, maintains key enterprise metrics, and determines the business and feature epics for the enterprise that will ultimately go on the ARTs at the program level. As expected, the portfolio level also has its own artifacts, roles, and teams.

SAFe obviously is a large undertaking. Successful implementation requires consulting experts and tools, so training and investment are key for success. However, SAFe has a handsome rate of return, which is why more firms are undertaking a change to this framework.

SAFe represents new thought leadership within agile. Agile at the team level has matured, and that is not a bad thing. But the community needs a methodology to take the agile practices to the next step: the enterprise. SAFe may be worth considering as the solution for you and your business process.