We had the opportunity to apply the updated version of the framework at our assignments, and here are its key updates, the positive changes it brings and the areas that still require attention.

Updated: november/2023

SAFe 6.0 has been making waves in the agile community since its release in March 2023. As organisations delve into this updated framework, it’s crucial to understand its capabilities and limitations. Just as importantly, it’s essential to recognise that SAFe is not a one-size-fits-all solution and requires customisation to fit specific organisational contexts.

SAFe is still a framework.* It helps you with a lot of practices.
But it doesn’t give a direct answer to your challenges.
Always search how it suits your organisation and the different environments within it.
It is not one size fits all. It is not a blueprint. It is not your target operating model.

* Check our guide with main challenges + tips to face them when starting to deploy SAFe

1. What are the key elements of the update?

SAFe 6 brings us… guess what, six major changes.

With a focus on enhancing business agility and incorporating Lean principles, we see that SAFe 6.0 offers valuable guidance for organisations navigating complex transformations. Scaled Agile promises us six primary themes in the updated framework:

1. Strengthening the Foundation for Business Agility
2. Empowering Teams and Clarifying Responsibilities
3. Accelerating Value Flow
4. Enhancing Business Agility with SAFe across the business
5. Building the Future with AI, Big Data and Cloud
6. Delivering Better Outcomes with Measure & Grow and OKRs

It does feel like the themes are there to match the new version number. For example, we don’t see the need to separate Business Agility in two themes (1 and 4). Strengthening its foundation and helping spread across the business could perfectly go together. Besides that, Measure & Grow, as well as OKRs*, could already be found at SAFe 5.1 (respectively, on top of the framework and within Strategic Themes).

*Check our free guide for defining OKRs

2. What are the best changes SAFe 6.0 brings?

A. Program is dead

Scaled Agile spent a good effort to kill the Program message across the framework. The Program layer is now ART Flow. PI stands for Planning Interval. And SPC’s are now called SAFe Practice Consultants. In practical terms, we noticed this helps clarify to our customers that SAFe isn’t intended to be just another format for a Project or Program approach.

B. Business Agility more embedded

One of the biggest challenges we see in Agile transformations is building the connection between the business and solution development. The idea that business has to be involved in value delivery has been there for a long time. With the new 6.0 update, SAFe brings much more guidance around how to embed business in your ARTs – or even how to create Business ARTs. In different kinds of challenges, this helps and inspires to bridge the gap between business and development. It also helps to avoid the perception that SAFe is as an IT-delivery oriented framework.

C. Lean & Flow at the core of SAFe 6.0

Until now, SAFe has embedded Lean Thinking in their own “SAFe House of Lean”. We are happy to see that it is now moving towards its origin and based on the principles of Lean Thinking. Important topics like “Respect for People” and “Relentless Improvement” are now moved to the Core Values.

By explicitly addressing Flow with the naming of the Lean Thinking principle “Make value flow without interruptions”, and by renaming its different levels, the new SAFe framework enhances the importance of flow and clarifies how to implement it. This is further enhanced by “The Eight Flow Accelerators” within the principle, which we also noticed can really help to drive the Lean mindset.

3. What can still be improved?

A. Different configurations miss crucial elements

All the four presented configurations are somewhat confusing. In specific parts, you can easily miss topics and guidance. Of course it is valuable to make the framework less complex for smaller environments. But when you use the essential configuration, you miss for example the following aspects:

• Business Agility
• Measure & Grow
• Strategic themes and OKR’s

What we see in reality is that also for smaller or less complex environments these are crucial elements. 

B. New tech elements feel like buzz words

By addressing Big Data, AI and Cloud, Scaled Agile jumps on the technology bandwagon. We see here two risks:

1. Technology’s future is not directly related to a layer, nor to a specific SAFe configuration. As a single ART, AI or Big Data can be an important topic.
2. There are many other technology trends which have not been mentioned next to those three. Think of IT Automation, Extended Reality and Robotics, to name a few. Are they any less important?

Even as a single Agile Team (so, hopefully not using SAFe…), different technology trends are valuable, and each can fit better to specific organisational contexts and challenges. By choosing to include three of them, we see a trend in companies rushing to prioritize those three over other technological breakthroughs that could be more relevant for their needs. Of course it would be impossible to integrate all of those technologies into one framework. So, in our view, it should be more about creating the mindset for new technology possibilities and being open to them, alongside guidance for assessment and adoption (and ensuring this is part of every SAFe configuration).

C. Roles are unclear and seem a bit hierarchical

The updated framework makes a good progress when it comes to clarity about the responsibilities and collaborations of the different roles. There is very good guidance here. However, when applying the framework at our customers, there are moments when it all feels unclear and hierarchical. We feel some improvement could be achieved by making it simpler and less traditional. We’d suggest:

1. Including guidance on collaboration for every role. At this moment, the framework brings collaboration guidance only above team level (ART and Solution Train). But collaboration is also crucial for the Agile team members / roles.
   
2. Remove the words ‘Management’ and ‘Engineer’ from roles naming. From what we see out there, a good way of avoiding traditional thinking and making a clear distinction between ART level and Solution level would be to use more direct role naming, such as:
   • From ‘Solution Train Management’ to ‘Solution Owner’
   • From ‘Product Management’ to ‘System Owner’
   • From ‘Solution Train Engineer’ to ‘Solution Flow Master’
   • From ‘Release Train Engineer’ to ‘System Flow Master’
     
     We still face a challenge to find alternative naming suggestions at ART level. Let us know if you had good ideas!
     
3. Avoid “doubled” role names. We were happy to see they fixed the naming of “System Architect / Engineer” to simply “System Architect”. But at the same time, they went from “Scrum Master” to “Scrum Master / Team Coach”. This isn’t very clear on what to expect. If the point was to avoid relating directly to Scrum, we think “Flow Master” would have been a better solution.

See also: Switching from Scrum Master to Release Train Engineer

Our impression about the updated SAFe 6 framework

After a few months using the updated framework, we believe that the steps SAFe has taken are a considerable improvement. It promotes more clarity on roles and responsibilities, as well as by removing the word Program. It also brings relevant focus for specific topics, like Respect for People and the spread of Business Agility beyond the teams and ARTs. However, we also see some opportunities that are “low hanging fruits” we hope to see improved for the next updates.

Related Articles

• Scrum Guide 2020: Is It Still Agile?
• Agility at Scale: How to Deploy It With SAFe?
• Enterprise Architecture and Agility are on the same side
• The OKR Method: Why and How to Adopt It? (With Examples)

In Summary