When to use SAFe (Scaled Agile Framework)

There is a huge debate in the agile community around the SAFe framework.
A lot of agilists seem to pretty much hate it.

Ken Schwaber for example: unSAFe at any speed. Ken’s main criticism seems to be that consultants and creators will make money from it through training and consulting. Completely unlike Scrum obviously.

And David Andersson, Kanban-the anti safe for almost decade already. Main criticism seems to be that it is not Kanban (the new silver bullet) and that the implementation approach is big bang.

The SAFe criticism I find most relevant and that I am commenting on in this post is:

  • SAFe uses centralized control
  • Implementation is big-bang push
  • SAFe is big and prescriptive
  • SAFe uses big batches
  • Lack of clear connection to customers and end-users

Before moving on, first a disclaimer. I have not been to any of the classes, I have only read the book and studied the website. I have not used the full framework, I have only worked with clients where we have used inspiration from it. And I have an experience where we ended up with something a bit similar to SAFe before it existed, because we needed to scale the decision making.

And before commenting on the criticism I will discuss when NOT to use SAFe and when it might be useful.

When to avoid SAFe

Scaled Agile Framework is, as you can figure out from the name, a framework to Scale agile. If you have no need to scale what you are doing, you won’t benefit from it – instead you will create a lot of waste, limit your capability to deliver value and limit your flexibility. If all you need is Scrum/Kanban, XP and Scrum of Scrums than you are well advised you stay far away from SAFe. If you are not yet doing Scrum/Kanban, XP and Scrum of Scrums it is probably better to start with that and add more complexity if/when needed.
If you have limited business and technical dependencies and coordination needs (or if we you can achieve that) you are likely much better off scaling in a way more similar to Spotify’s approach. It is a far more agile approach with decentralized decision making. At the center of the value creation we have Squads: “ideally each Squad is fully autonomous with direct contact with their stakeholders and no blocking dependencies to other Squads. Basically a mini-startup”. This is combined with: “Spotify technology is highly service oriented. We have over 100 distinct systems, and each can be maintained and deployed separately”.
At Spotify no customer is ever ordering a set of features across a number of products that needs coordinating with all other customer orders.
If it is possible to achieve this in your organization please forget you ever heard about SAFe!

When to use SAFe

If you have significant business and/or technological dependencies or coordination needs you might benefit from SAFe.  The organization does not even need to be big for this to be the case, see scaling-agile-in-small-organizations.

In a previous assignment the client had 20 teams delivering into the same product line (using configurations to deliver a family of products). They had a multitude of clients world wide and most of the time clients purchased the whole solution with some new improvements – usually based on work from most of the 20 teams.  If someone can explain to me how to make that work with fully autonomous teams and decentralized decision making I am extremely interested in listening! Please leave a comment. Or if someone can come up with a structure that is completely different from SAFe I am also all ears. Since we couldn’t figure it out they used SAFe as one of the inspirations for the set-up.

At my current assignment the situation is similar, we have 20 teams delivering into the same product portfolio. Clients are purchasing solutions which might be built from several of the products in the portfolio. The set-up here is also inspired by SAFe.

In both these cases I believe there is a continuous and large need for coordination and prioritizing across the teams – and I believe a SAFe similar approach makes sense.

Could the teams do this themselves in these situations, without a hierarchy of decision making? Maybe, if all had access to the same information and shared the same view on vision, strategy, cost of delay (which in reality are changing quite often), risks, opportunities, competition in different marketplaces, future market trends and so on. And had personal relationships with major client decision makers (one phone call can significantly change the cost of delay in 30 minutes). For the complete family of products and on all levels. Personally I have a hard time seeing this happen across 100’s of people across dozens of products or product areas that are connected into client solutions.

Comments on criticism

SAFe uses centralized control

As I have argued above on when to use SAFe (and when to stay away), I consider the need for some level of centralized control the main reason for using SAFe. Even though I consider myself an agilist I don’t consider some level of centralized control as the evil anti-thesis of agile. I consider it a necessity in many organizations. Yes, it will make us less agile, but there is a trade-off between agility and a holistic system view and sometimes the system view wins. “Optimize the whole” as we say in lean speak. The goal is to deliver as much value from the system as possible – it is not to be as agile as possible. I think some agilists have mixed this up.

If all decisions in a large interconnected system are localized we are guaranteed to sub-optimize. For a fully self-organizing system built from a network of self-organizing teams to work we have to assume that all relevant information for decision making is available at team level. You could argue that at the level above the teams it should be a team of Product Owners that are self-organizing the Program Backlog into the right order. In fact, it is pretty much the core of the set-up we have used in one of the examples I’ve mentioned. But I would argue that that is not enough in many cases. First of all – these Product Owners does not have the PO team as their first team. Their first team is the Scrum Team. Secondly, when it comes to hard priorities they are bound to have some bias towards their own teams and product. And third, in reality they can’t be everywhere at the same time. In large scale agile Product Managers are often flying all over the world meeting clients, negotiating contracts, working with marketing on setting up campaigns etc and it is impossible to both do that and be available to answer detailed questions about a small User Story for the team. Which is why they have split these roles and split the decision making in SAFe.

It makes sense to give up a bit flexibility and speed in decision making to make sure we are building the most valuable things. I think it is dangerous to only use the agile parts of our brains when thinking about large scale agile. We also need to use our knowledge and understanding of lean, systems thinking – and maybe even more importantly common sense.

In my experience the key to make centralized decision making work in an agile context is  is to have clear levels. For example, if using SAFe you end up with Product Managers who are not working closely with the teams and in collaboration with real end-users that still try to decide over every single User Story in the team backlog you will likely get into trouble. As long as the decision makers clearly stay within their level of insight and don’t try to control details they are not the one who are most familiar with it can work well. This is however a challenge, and something to keep a close eye on.

So far I have talked mainly about business control. Technical control and coordination I believe can be managed through self-organization – although it is challenging. I have experience working with three teams without an architect or overall technical decision body and that is fairly easy. But with dozens of teams and hundreds of people it is of course quite a bit of a challenge. You might not be capable to do this at the start, when the teams are not yet teams, and the organization is not yet advanced in facilitating self-organized decision meetings. But this might be a goal even if you start out the way described in SAFe.

Yet another aspect of control is around the teams and the level of self-organization they have. Essentially there are three different aspects to consider; self-directed, self-selected and self-organizing. When most organizations talk about self-organization they usually mean that the team decides who in the team is going to do what and when and teams are responsible and accountable for their own work and results. The self-organizing team “commits” to a plan with the Product Owner and then it is up to them how to solve it – and initiate a new discussion when they can’t solve it. Self-selected means that the individuals in the organization choose themselves which team they will work in. Self-directed means no on else can direct the team in any sense, this usually means fewer managers or that managers no longer are leaders in the organization.

Larman and Vodde have taken self-selection and self-direction pretty far in their LeSS framework. Larman shares a story of self-selected teams in “How to form teams in large scale Scrum“. The empowerment of these teams and the motivation you get is very powerful. I do however have some concerns and some experiences. I believe there are  risks with taking the self-organization too far. I share some of those thoughts and experiences in “Be careful with self-directed and self-selected teams“. I think that we may not know the whole story yet either, because these are fairly new experiments. I think sometimes it will work out fine and sometimes not.

Implementation is big-bang push

This seems to be David Anderson’s main concern. I agree that there are risks with doing this, but at the same time I assume that David is a lean expert and therefore very familiar with Kaikaku (radical change). Kaikaku is quite the opposite of the Kanban method which is all about Kaizen (continuous improvement). But sometimes there truly is need for radical change and if SAFe is a good fit to what your company needs right now it might be worth the risk implementing it in six months rather than starting with Kanban and wait five years for something similar to emerge. I have consistently positive experiences from use of Kanban, but system wide improvements have in general been quite slow.

Sometimes the risk of waiting is much higher than the risk of radical change. Word of advice is to consider carefully before doing a big bang push – it is guaranteed to create turmoil in the organization and take time away from the value you are delivering right now. And try really hard for a way to customize SAFe so it fits your organization and implement it in smaller pieces. I would advice against doing a full SAFe implementation in one batch.

SAFe is big and prescriptive

Based on our experiences with RUP we have learned that it is very hard to scale down from a big prescriptive process (it is scary to remove something from the process when your knowledge and experience is limited). It is easier to scale up than down – but that turns out to be quite hard as well and that is the reason SAFe exists. I consider this a major risk for ambitious SAFe implementations. Advice is to be very careful, take what you need and always look for other options as well. For example, I have experience with four different patterns for successfully scaling the Product Owner role, but SAFe offers only one pattern. It is the same with most things in SAFe, it offers one pattern when there are several other known and trusted patterns in the community. Different patterns fit different contexts. The good thing with this is of course that it makes it far easier to communicate and implement – which is probably the biggest strength with SAFe.

A piece of advice is to consider carefully if all your teams need to be included in your one-size-fits-all SAFe implementation. Even if you have coordination needs across many of the teams and products there might well be teams and products that could be allowed more agility and speed and be left outside of the centralized control. These teams could work more like lean start-ups, autonomous teams with continuous flow. Don’t smother these teams and products with SAFe!

SAFe uses big batches

In lean and agile we are generally moving towards continuous flow of value. But SAFe is built on batches on Sprint and PSI level. Personally I believe this is a good stepping stone towards increased coordination and control over the whole system in many contexts. But for the long-term you should aim towards more continuous delivery. And in the future you don’t necessarily have to connect your delivery cadence with your planning cadence when the organization becomes more advanced in agile (for example in Continuous Integration and automated testing) and ways of working.

Lack of clear connection to customers and end-users

I find SAFe quite silent on how to make sure we create the most value in the system. Looking at the division of responsibilities between Product Manager and Product Owner you get the impression that only the Product Manager is meeting customers. I think it is really hard to successfully prioritize and elaborate User Stories without some direct access to customers and end-users. Validated learning (term from Lean Start-up although the idea isn’t new) isn’t mentioned at all as far as I can see, but it is something I consider extremely important. In software development we have a history of 45 % of the features we develop that are never used. Measurements of actual usage after release are an instrumental part in finding out what is really valuable and truly easy to use. In my experience it is far from always the same thing users (a few representatives) and customers thought before the release. And that is just a small part of what we will find out when we start  measuring the usage of our products in a systematic way. Other things might be for example:

  • 90 % of the customers starting a purchase leave before finishing
  • It takes in average 12 minutes to finalize a rest order – we expected it would take 2
  • Half of our users jump several times between the settings configuration page and the user manual when changing a setting
  • After launch of “improved” image modifier usage has decreased with 40 %

Personally I believe we need access to customers, end-users and access to information on actual real usage of the system on all levels. Product Owners should probably have the most intense end-user contact and some customer (purchase decision maker) contact. Product Managers should have the most intense customer contact and some end-user contact. The rest of the team should at least occasionally get direct feedback and information from end-users. My advice is to study Lean Start-up, it’s good!

Some good parts

The overview picture – It gives a good overview and is  fairly easy to explain. If you have ever been asked “so how do we scale up and coordinate the work of all the Scrum teams then?” you have probably ended up with something similar to this picture (when the right answer clearly has not been – you don’t, you use autonomous teams working as lean start-ups).

The website – It has a lot of good content and advice which can be helpful.

The decision levels – I think the three different levels; Portfolio with Epics, Program with Features and Team with Stories are useful in many situations.

The product focus – This is a major thing that might not be instantly visible. But with SAFe comes a shift from projects to products which is hugely beneficial for many reasons. I have worked with several clients were projects have been one of biggest impediments to an agile transformation (short lived teams, date focus, lack of long term investments in competence development, technical improvements and so on). Only use projects if it truly is a project (temporary organization, unique product). The project format is usually very wasteful for continuous development of a product that already exists – and it is an effective blocker to agile transformation.

The team focus – Long lived, cross-functional teams are at the core of SAFe. This is great!

Based on Scrum and XP – If you know what you’re doing, these work really well!

Focus on Code Quality – “You can’t scale crappy code


In conclusion I think SAFe is mostly good and it certainly fills a void when it comes to advice on how to make agile work at scale. In my opinion there are no better options available at moment if you have a large, complex organization with significant coordination needs. Apply with common sense, Inspect & Adapt and don’t consider it an ideal end-state and I believe you will benefit from it.

In the future when agile and lean knowledge has more spread and understanding I can imagine that SAFe might be replaced with mature pattern catalogs where we can pick and choose patterns depending on context and needs – but I don’t think we are quite there yet.

If you don’t need it – don’t use it.


1 thought on “When to use SAFe (Scaled Agile Framework)”

  1. Phillip McDonald

    Great comments. I appreciate the balanced view. In a lean world, there is no best and smart organizations know this and adjust. I have found SAFe good for game changers that impact a sizeable part of the business. It brings in quickly the organizational impediments and allows leadership to focus on the change.

    Results matter. Pick the right level of agile for your value based outcome.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top