Some Organisations Are Better Off With SAFe Than With Scrum
As long as you know what you are doing
As long as you know what you are doing
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Fe200ffff-18d7-4c93-8356-bbe441c32160_800x535.jpeg)
The Scaled Agile Framework (SAFe) and Scrum are both ways to help organisations to deliver value. Both qualify as Agile approaches. People may disagree about this. Some argue SAFe isn’t ‘Agile’, others even argue both aren’t. That’s fine. I’m not going to discuss this here and now as this is not relevant for this article.
SAFe is heavily inspired by Scrum. It has Product Owners, Scrum Masters, Scrum-like events and much more. Still, SAFe doesn’t work with Scrum. Here are some key differences:
SAFe has more roles, events and artifacts than Scrum. As a result, SAFe is more complicated than Scrum.
Product Owners don’t own the Product Backlog. Instead, the Product Manager has the final voice, although it is about the Program Backlog.
The Sprint Review as a pivotal event to discuss the course of the product with the stakeholders doesn’t exist. Instead, SAFe has Inspect and Adapt events at the end of an Agile Release Train consisting of several Sprints. With that, SAFe’s feedback loops are longer.
SAFe alters or takes away key elements from Scrum. With that, SAFe is less equipped to create valuable products in complex environments. Still, some organisations may be better off with SAFe than with Scrum. Here are three reasons why this can be the case.
No complex product environment
Scrum is a framework to deliver valuable products in a complex environment. All rules, events, roles and artifacts in Scrum serve this purpose.
SAFe has the following purpose:
“To enable the business agility that is required for enterprises to compete and thrive in the digital age.” — SAFe5.0/about
SAFe wants to get every part of the organization involved in delivering technology-based solutions. SAFe accepts longer feedback loops than Scrum. As a result, SAFe is suited for product environments that aren’t very volatile. When it is OK to have 6 to 10 weeks between feedback moments on your working software with your key stakeholders, then SAFe is fine for you.
If you need to have feedback loops of a month or less because of the complexity of the environment, then SAFe is a poor choice.
No willingness to recognize the complex product environment
Organisations may be working in a complex product environment, but unwilling to recognise this. Before you dismiss this as a cheap argument, please hear me out.
For more than a hundred years, we have lived in a world where Scientific Management has flourished. Efficiency, standardization and best-practices are key words of this world.
Today, many organisations have come to understand that the world isn’t this simple. A complex world needs a different approach to achieve success. Many other organisations though still believe in scientific management. They don’t recognize that their product environment is complex, requiring fast feedback loops to be able to adjust course. Therefore they prefer SAFe over Scrum. They may acknowledge some uncertainty, but still, holding on to the security and familiarity of a delivery model like SAFe provides comfort.
SAFe fits the organisation like a glove
SAFe has many roles, especially the larger adaptations of the framework. Many will recognize themselves somewhere on the SAFe overview. We see architects, different (management) layers, product managers and more. On the surface, an organisation structure doesn’t have to change much to adopt SAFe.
Scrum doesn’t have this. You’re either part of the Scrum Team or you are a stakeholder. Everyone needs to find a new place to interact in or with a Scrum team. Scrum is intrinsically disruptive. Scrum enforces change. With that, Scrum is more scary than SAFe.
No combination
SAFe and Scrum may be strongly related, you can’t use both of them at the same time.
Scrum only works when you adopt all rules, roles, events and artifacts as this allows empiricism on Sprint level. SAFe aims at closing the feedback loop at the end of the Progam Increment. With that, it is different than the Scrum framework.
If you aim to use Scrum by the book while you work in a SAFe environment, you should honestly ask the question if you do this for the right reasons. Using a framework like Scrum shouldn’t be a goal in itself. Shoehorning Scrum into SAFe while Product Backlog, Product Owner and Sprint Review don’t exist or have a different role doesn’t make sense.
Inspect and Adapt
Whatever framework you choose to work with, it is crucial to understand that with both it is essential to constantly inspect and adapt the way you have adopted your framework or process. You are not done when you implemented Scrum or SAFe. You need to identify what doesn’t work, what works well and adapt. Sometimes this can lead to moving away from the approach:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” — Principle of Manifesto for Agile Software Development
If you choose your framework well, you probably don’t need to move away from it as you can improve within the particular framework. However, if you don’t allow for this ultimate decision, then you are not taking inspection and adaptation at heart. With that, the approach becomes more important than the goal.
Suppose that you conclude that SAFe or Scrum doesn’t fit you anymore. Can you move away from it easily? The bigger and more complex a framework is, the more difficult and costly it is to implement. And when you decide to abandon it, it will prove to be an enormous effort. Moving away from SAFe will take considerable effort and will be disruptive for an organisation.
If you wish to abandon Scrum, this is easier as this is at the team level. One team in an organisation could decide to stop working with Scrum while other teams continue with it.
Endnote
Sometimes SAFe fits an organisation better than Scrum. This can be when:
The product environment isn’t complex;
The product environment isn’t considered to be complex;
SAFe fits the organisation model well.
Whatever approach you choose, you should aim to:
Create high-value products;
Allow for relentless improvement, even if this means moving away from a framework.
Whatever you choose, make sure that you are not stuck with a framework once you notice that it doesn’t fit anymore. The end goal is not to implement a framework but to create high-value products.