Last updated on | Agile General Knowledge

MY Opinion in Why SAFe is the best Scalable Agile Framework

by Luís Gonçalves
Scalable Agile Framework scaled agile framework


Hi guys, this week I want to explain why I believe SAFe is the best Scalable Agile Framework.

Last week I had a chance to participate at a MeetUp where the main topic was LeSS. As you might know, LeSS is one of these new fancy scaling frameworks, or at least this is how they sell it.

I want to be very clear, I am not a SAFe consultant, and I do not get any commission from SAFe. I had an opportunity to work for a couple of years with a company that implemented SAFe, and I believe SAFe will be the most successful framework. Some time ago I wrote a blog post about the topic “Why SAFe will succeed” but today I would like to elaborate a bit more.

Scaling Frameworks

SAFe, LeSS, NEXUS and many others frameworks are sold as “scaling” frameworks. Are they allowing companies to scale anything?  The way how I see it is that they are frameworks that enable parallel work. Let´s be very clear: THIS IS NOT SCALING!!! THIS IS GROWING!

Some time ago I attended the conference where I listened to the speech of a CEO of the Munich-based company. He was super proud describing to the audience how his company scaled from 10 teams to 100 teams. I just wanted to say out loud: “This is not scaling, it is growing!”

For you to understand what I mean by this saying,  I found an excellent definition of both terms in

Growing means you are adding resources at the same rate that you’re adding revenue. This model occurs constantly in professional services business models – they gain a client, hire more people to service the client, and add revenue at the same exact rate at which they’ve added more costs. While they’ve technically “grown,” they haven’t scaled.


On the other hand, scaling is about adding revenue at an exponential rate while only adding resources at an incremental rate. Google has clearly demonstrated this concept by adding customers at a quick pace while adding very few additional resources to service those customers. That’s why they were able to increase their margin at a rapid rate in just a few short years.

Are you able now to figure out why all these frameworks do not solve any scaling problems? But then again who can blame them? They just create solutions the market wants after all everyone wants to have a recipe.

Everyone intends to have a silver bullet to solve all the problems, but unfortunately, this is not possible, and sooner or later companies that implement this kind of frameworks will realise they spent millions for nothing.

In my opinion, if you want to scale you need to identify the constraints in the whole chain and see what is preventing you from having the 10x impact in your actions. This is only possible if you have a framework that looks at the organisation in a holistic way. A framework that takes end to end implementation, system thinking, flow, and theory of constraints into consideration.

So let´s take a look at three different frameworks.


Scalable Agile Framework


Scalable Agile Framework


Scalable Agile Framework

Which of these frameworks is:

  1. Paying attention to the whole system and not only to the software development part?
  2. Helping to identify the overall flow, value chain and the end to end implementation?
  3. Connecting company strategy with daily operations?
  4. Taking a holistic view of the whole organisation?

Yes, SAFe does that.

Why SAFe is the best Scalable Agile Framework

SAFe has its many problems. I do not like how SAFe takes care of DevOps/System Team. And especially I do not like how SAFe supports functional teams instead of cross-functional teams.

But for example, SAFe integrates portfolio management that no other framework does. In my opinion, this is one of the big enablers for business scalability.  Johanna Rothman wrote a fantastic book explaining the benefit of portfolio management in our companies if you have time take a look at it right here.

The truth is much more painful than what companies want to accept… There are no frameworks that will solve your problems. Frameworks might be a good starting point, and I believe SAFe with the right coaches is one of the best places to start.

You can start with functional teams instead of cross-functional teams.  My experience tells me that you will have dependencies all over the place. And you will be far from being truly Agile (cross-functional teams), but it is a place to start.

With good coaches on board, they will be able to map all dependencies. They will be able to coach the organisation to do the necessary changes to move to a truly cross-functional company. And they will be able to implement improvements along the way.

SAFe is one of the frameworks connecting all the dots… With the right coaches,  SAFe will make a difference. In my vision, the other frameworks only do parallel work not solving any scaling issue.

I know this blog post is quite polemic, but this is my opinion. Do you want to start a discussion? Simply leave a comment.


We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team CoachingAgile Training, and Agile ConsultingOKR TrainingOKR ConsultingInnovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker that works exclusively with Senior Executives of 7 to 8 figure businesses on the deployment of his game changing ‘Organisational Mastery’ Methodology.


Share your point of view

  1. Hey Luis,
    I enjoyed the article. An interesting thought came to mind though.

    Each of these scaling frameworks I see (including the “Spotify Scaling Model”) seems to not really touch on the process of how we work out what to build. The entire art/science of product ownership, product management and portfolio management is usually touched on very briefly if at all. It seems like a lot of these frameworks consider topics outside of software delivery “out of scope”.

    Given this, if you were to implement LeSS or Nexus at a company as a coach, you would probably recommend including portfolio management at the C-level, in the same way you would recommend teams to be doing automated testing and continuous delivery.

    What are your thoughts? Do you think LeSS and Nexus are inherently opposed to the concept or would they slot in nicely to some portfolio management activities?

    1. Hi Ryan,

      Yes I think if LeSS or Nexus would include Portfolio Management it could be a great asset. Like I explained in the article, I believe the biggest value is there.

      LeSS and Nexus is pure Scrum which I like but it misses the whole business connection, they are another way to do sw development. If you wanna cause any impact you need to bring Portfolio Management to the equation.


  2. When I see these framework diagrams my only thought is “OMG! How could we have gotten here?” :facepalm:

    > There are no frameworks that will solve your problems.


    > Frameworks might be a good starting point and I believe SAFe with the right coaches is one of the best places to start.

    If it needs the “right coaches” to possibly be a “good starting point”, I’d argue that it isn’t a great framework at all.

    Don’t get me wrong, I completely understand the allure to top management of having a “framework” to put in place where people can be cogs on a well oiled Agile™ machine, especially in the typical command-and-control style on management so common in our corporations, following the “factory mentality” and the search of reproducible recipes for success.

    Yet, true agility is all about *people*, that messy non-standardised resource that is so difficult to “manage”, not about this or that process.

    Like a work colleague once said, it would have been interesting if the 5th point of the Agile manifesto was “Knowledge and experience over certifications and seniority”.

    Get experienced people on board (managers, coaches, techs) which have the experience and know how to do these things, and they’ll grow/scale the company to become agile within the constraints, culture, etc. of that company.

    Then they just need to resist the temptation of making a diagram and slapping an backronym on it to sell as a framework 😀

  3. (I’m trying my best to leave my own personal biases out of this)

    [1] The “best” in which context? I think that is the first important question to make, when

    [2] I am yet to see real-world data on how SAFe actually has helped companies be more prosperous and I would like to see that from companies that are at least 18-24 months down the SAFe journey. I don’t have enough data points to answer the question and the three (each a major big org) that I can think of right now, are all negative.

    1. Best does not mean that actually works 😉 I pose the same questions that you did to the other ones 😉

      And I belive I was clear 🙂 I am talking about scalability 🙂

  4. For me the biggest advantage of SAFe over others is that SAFe is not bounded to one method like SCRUM. One cas use Kanban or XP in SAFe and still be successful in an agile world. Isn’t it all about agile to be able to adapt to the situation quickly? SAFe does it in my opinion. Luis, thanks a lot for this post!

  5. Scrum does include the business connect, aka Product Owner. That said, Scum is the basis for SAFe and then SAFe builds upon it additional practices that drive to other areas like Portfolio Management. Scrum looks at a product, so it doesn’t fit in Scrum or Nexus, but certainly does fit within SAFe. Nexus too looks at a single product, but multiple teams working on that product. So again, running Nexus in a SAFe environment works quite nicely and we have seen that done and being done.

  6. Luis,

    The book you mentioned is project portfolio management. SAFe doesn’t have projects. In fact, SAFe explicitly chooses product-based definition for portfolio management. That is something very very different. Can you explain what you mean with portfolio management?
    I could explain how LeSS possibly deals with the need for portfolio management.

    1. Send me an email, this is a too long discussion to have it here… Does not matter if its project or product… The idea is to have Portfolio, that is the main idea.

  7. instead of looking to see what is best, might be better to see what do each do, where do each fail, what is the right mindset, what are the needed practices. As a SAFe SPCT I am obviously a backer of SAFe. But the question shouldn’t be – which is the best framework as what do you have to do and how can we use the existing ones to do what we need?

  8. The context is not scaling. The question is “scaling is within which context”. Scrum is a core governance tenant on which SAFe & LeSS is built. The problem is that Scrum only works effectively in certain contexts.

    Have you seen this recent blogpost – ? This is one example of context. I think that an important point is that if you want to understand scaling you need to understand how to apply systems thinking first.

    1. “The context is not scaling” which context? Because here is what I disagree completely… These frameworks appeared exactly to scale so I do not get your point.

      “his is one example of context. I think that an important point is that if you want to understand scaling you need to understand how to apply systems thinking first.” Thats why I say portfolio is super important because only then you can have an overview the whole system.


  9. I also do not like the way SAFe takes care of DevOps/System Team. In reference to DevOps I really appreciate —
    As for me, it’s a great DevOps solutions provider. Would love to hear your thoughts about it. Thanks.

  10. Why am I not surprised that SAFe offers all the advantages of Kanban by integrating Kanban? This article is bullshit.

  11. Hi Luis. I want to make two points:
    1) Growing and scaling are grammatically synonymous. To use one persons different interpretation to support your argument is flawed.
    2) I don’t want a framework that is “a good starting point”. I want one that shows me where I should end up. The USP of SAFe is it’s Agile Release Train, but it’s unrelated to releases. It is actually a Planning Train. And who wants to plan big batches of 8-12 weeks at a time? More of my thoughts here :

    1. It seems that even HBR agrees with my definition:

      “They confuse growth for scaling. Growth means adding revenue at the same pace you are adding resources; scaling means adding revenue at a much greater rate than cost.” (

      If you still believe that HBR is not a reliable source than I do not know what I should write 😉

      About you wanting a framework that shows you the end state, you have one called crystal ball 😉 buy one and then you can see what will happen.

      It should be time for people to understand they cannot get the end state… We live in an extremely complex world with complex environments in our organisations… The end world is always unknown… But we need to start somewhere…


    2. I’m late to this party, but I can make the same comment 1 or 2 years late and it seems still appropriate. Since I cannot reply directly to Luis’ reply to Ryan, I am replying indirectly by way of Ryan’s comments because I believe he (Ryan) is correct:

      (1) “Growth means adding revenue at the same pace you are adding resources; scaling means adding revenue at a much greater rate than cost”. Neither of those definitions can be considered the norm and in fact seems to have very little support even years after first being promoted by HBR or Fundable. So in normal parlance – even among “scaling framework” pundits, they are not splitting that hair because it fundamentally does not matter – both are good things for a business.
      (2) Even if we accept those definitions, the fact that a validated benefit of implementing proper agile practices is a multiplier on ROI (cost reductions, reduced schedules, doing more with less…) makes the definition of “scale” absolutely applicable for any agile scaling framework. The company that grew from 10 scrum teams to 100 did in fact scale (it is unlikely they hired 90 scrum teams – what they did was convert old practices to agile ones and benefitted as a result – they scaled).
      (3) Even if “scaling” is different from growth, there is no inherent reason to believe that SAFe “scales” better. There isn’t necessarily anything wrong with SAFe, but it is not what its name implies – it is not an agile framework – it is a framework that includes some agile. If it is more widely adopted, that only means it is more successful in selling itself – it does not mean it is better at achieving the objectives (you know the old Betamax vs. VHS, story, right?).

  12. Good things that this article brings out (while other frameworks missed them)
    1. SAFe using the portfolio as the right place of leverage in enterprise.
    2. The flow from portfolio to team.

    The big items that this article miss are:
    1. SAFe’s big appetite for making money. Looking at the big business model they have created just out of certifying anyone and everyone, and expensive yearly renewals.
    2. Cross functional initiatives at enterprise level and lack of clarity around that. Though epics and capabilities are touted to solve them, they don’t in reality. To some extent LeSS Huge helps using Area Product Owner and Team Slicing concepts.
    3. SAFe has modified some elements of Scrum and clouded the knowledge body that is maintained well by Jeff and Ken.

    However, SAFe is clearly winning more than others. But, an agile purist looking at SAFe big picture, will immediately develop dislike triggered by process and control heavy feel from big picture. A better source to learn about SAFe is the book by Mohammed, ‘Get SAFe Now’ – And I definitely do not recommend training such as Leading SAFe or SPC because they are expensive, very PPT centric run by money minded trainers, and yearly renewal liability to keep the certification.

  13. Hello. Well, interesting, but SAFe seems not Agile at all.
    All these people wrapping the Agile process is like a try to conquer the place that they deserve to lose years ago.

    In Agile, the part doing Agile GROWS to let other parts of the Organization to SCALE. What SAFe propose is to SCALE the effort of few people (Agile workers, ocassionally developers) to GROW the waste (people with nice jackets, hats and ties). It’s funny how the “important people” wants to be “around” the Agile process and not to be part of it.

    Don’t forget that Agile was invented by the people “inside”. Nobody will “invent” a framework to be the less important ones. So, even if SAFe works, it’s not what Agile tried to be. Now the question is, why SAFe whants to be recognized as an Agile framework? Answer: Sales.

    For the 4 points as “Paying attention to the whole system and not only to the software development part?”. If scaling is needed to solve that, then the problem is not the lack of scalability. These points need to be solved before scaling.

  14. Only companies that do not know what do for their customers will waste their time focusing on these type of big processes and methods. Every couple of years they will keep changing their process. True success always comes from organizations understand what their customers want and deliver it faster. How to deliver faster will vary between domains and companies have to find what works for them and stick to it