A Bit of History 

SAFe (Scaled Agile Framework) was created by Dean Leffingfell. First introduced in 2011, it was offered as a proven and publicly available framework for applying Lean and Agile practices at an enterprise scale, presented in a structured, interactive web format.

Over the years, this has changed. In the current “About” page of the latest iteration, SAFe 6.0, released in March 2023, is defined as “a knowledge base of proven, integrated principles, practices, and competencies for achieving business agility using Lean, Agile, and DevOps.”

SAFe Primer

There are three layers of SAFe:

1. Essential Layer

This layer consists of two parts. The first is the team flow. SAFe suggests using either SAFe Scrum or SAFe Kanban Team for the team flow.

SAFe Scrum is very similar to base Scrum, with differences in terminologies and some techniques that are part of the built-in quality techniques. SAFe Scrum is used by many companies when implementing SAFe.

SAFe Team Kanban is another Agile method that can be used, especially when the incoming workload is uneven and priorities are changing rapidly. SAFe Team Kanban is based on Kanban but with extensions such as the Product Owner, the Scrum Master/Team Coach roles, and a mandatory planning phase.

Another key concept is the Agile Release Train (ART). ARTs are Agile Teams that align to a shared business and technology over several iterations, where the suggested size is 5-12 teams. These ARTs coordinate their work every few iterations. A grouping of iterations is called a Planned Interval (PI) and usually consists of about 5 iterations. At the end of each iteration, there will also be a System Demo, showing the integrated result of all the iteration team’s work.

To make sense of this concept, let us assume we are working at Microsoft as part of the team that created Microsoft Word. Word is a massive application, so we may decide that each menu item could be managed as separate applications. To manage the development process, multiple teams would work towards the same goal, which is Microsoft Word. However, to coordinate the development, there would be one ART handling Word.

2. Large Solution Layer

The Large Solution Layer sits on top of the Essential Layer. At this layer, multiple ARTs work for one Development Value Stream as one Solution Train and could potentially consist of hundreds of people. 

Continuing the Microsoft example above, Microsoft Word, Excel, and PowerPoint will each have an ART team and are all part of the Microsoft Office Solution Train.

3. Portfolio Layer

At the Portfolio Layer, the company will coordinate all of its Development Value Streams to align with its vision and business opportunities. In our example with Microsoft, this layer consists of Microsoft Office, Windows, Xbox, etc.

These three layers could be configured to use only the Essential Layer, Large Solution Layer + Essential Layer, Portfolio Layer + Essential Layer, or Full Configuration Layer based on the company’s needs.

We can find the whole SAFe knowledge base in detail here. 

Pros & Cons

In the 15th State of Agile Report, 40% of the respondents were using SAFe instead of other Agile at scale methodologies. Due to its extensive adoption, it is likely that most of the terminologies and language used when talking to companies about Agile at scale come from SAFe.

With its 12-year history, SAFe has become a mature framework. It can be applied by smaller companies working only on one product, right up to enterprises working on multiple products within multiple categories of products.

In its full configuration, the company’s business side can communicate with the development side more effectively, and the vision can be easily disseminated to all stakeholders working on the product. 

SAFe allows guidelines to be established to give certainty to practitioners and stakeholders. Coordination and synchronization are done at every level, allowing management to predict results and keep everyone on the same page more easily. 

On the other hand, most things that make SAFe robust are the same factors that draw criticism. The relatively rigid structure of SAFe teams and the prescriptive guides are not popular with some Agile practitioners. The Planning Interval (PI), which takes about 8-12 weeks, is the most contentious part of SAFe because this means that our ability to adapt to the market is limited within that period. All of these make the critics of this framework feel that SAFe is not Agile enough.

Another issue is that many new terminologies used by SAFe may confuse non-experienced practitioners of SAFe. 

Some of these drawbacks could be alleviated with proper explanation or implementation. For example, while the rigid structure of SAFe is not appropriate for new startups, it could be a good fit for established companies and will help them leverage Lean and Agile in their company. The PI Period could also be tweaked based on the company’s needs, and one could argue that for big companies, 8-12 weeks is relatively quick compared to other methodologies.

Should We Use SAFe?

As we have seen, there are both pros and cons to using SAFe, as with any other methodology. The proliferation of practices, guardrails, and guidelines make SAFe seem unwieldy and too slow for companies that need to adapt to the market very quickly.

On the other hand, when we are working on multiple products that need coordination, SAFe is a good framework to utilize. SAFe themselves suggest that the minimal team size to implement SAFe is 50 people (or 5 iteration teams), so companies with smaller teams are advised not to use SAFe.

SAFe is also a valuable framework for when we operate within organizations required to adhere to regulatory standards, as seen in sectors like banking, telecommunications, or healthcare. In the Large Solutions layer, a robust compliance documentation approach and Non-Functional Requirements are included.

One thing to remember is that SAFe is not a silver bullet. We must look at our company and see whether SAFe fits our needs. SAFe is only a tool, and we need to use it appropriately to succeed.

SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

Author: Diaz Dwiastamika, Mitrais Technology Evangelist