But mediocre SAFe is disastrous
I am a Scrum fanboy. I love empiricism. I can go on and on about how great this simple framework works in complex product environments.
But…
Yes, there’s a big but. Many organisations don’t properly use Scrum.
Imagine you are a Scrum Master or Agile Coach working in a large organisation. Many of the teams can’t or don’t want to embrace vital parts of Scrum. Key stakeholders are beyond the reach of the Scrum Teams. The Sprint Review isn’t the inspect and adapt event you strive for. Together with your colleagues, you have spent the best part of two years to coach the teams and the organisation to adopt Scrum. But the results are negligible. Are you going to hold on to your ideas of a perfect Scrum world? Or are you going to help the organisation find suitable alternatives?
![](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%2F2bb6dc5a-3cf4-4b0b-a4cc-d03e4981723c_800x533.jpeg)
There may be various objections that prevent you from getting the best out of Scrum:
The wish to plan beyond one Sprint;
The wish to follow a plan beyond a Sprint;
No desire or even fear of feedback moments with users every Sprint;
No opportunity for feedback moments with users every Sprint;
Important stakeholders — like users — will not attend Sprint Reviews every week or two;
Important stakeholders do not wish to play a role at all your level. Think of Product Managers, Architects, C-level.
These situations may relate to:
The organisation model — the inability or unwillingness to include everyone in building the product and the inspect and adapt moments;
Relentless improvement — the inability or unwillingness to inspect and adapt during a Sprint.
Scrum can work for you
The objections I listed above can be overcome with Scrum this way:
Have a vision for your product(s). Align your Sprint Goals with that vision. Align your roadmap and plans to continue to focus on that vision. With a stable vision, you can allow deviations to the plan, the Sprint Backlog, to maximize chances to reach the vision.
Explain that in a complex environment, an incremental and iterative approach helps to meet your Sprint Goals.
If Product Managers are the ones with the vision instead of the Product Owner, ensure that they outline the roadmap and own the product. Encourage Product Managers to actually BE the Scrum Product Owner.
Ensure the Scrum Team has all the skills to create a Product Increment, including architecture skills. Yes, your architect should be part of the Scrum Team!
Build a Product Increment every Sprint.
Make Sprint Reviews true inspect and adapt events.
You don’t need to look for scaling frameworks to build your products, even if your organisation is big. You can do it perfectly with Scrum. If you struggle with Scrum, there’s a scaling framework closely related to Scrum that tackles potential issues with the Product Owner. LeSS, specifically LeSS Huge, solves it with Product Owners at a higher level and Area Product Owners working with the Scrum Teams.
But if you fail to address the objections I described, you will end up with a half-baked version of Scrum. A version that doesn’t deserve the name Scrum. When a team doesn’t involve important stakeholders and can’t use empiricism fully, it doesn’t work as a true Scrum Team. The team would only deliver features according to an almost immutable plan. They fail to regularly check if they are heading in the right direction.
When SAFe is a better fit than Scrum
So, the Scrum Teams have been doing half-baked Scrum for years. They are frustrated and don’t function as self-organising units. Management is frustrated because the Scrum Teams don’t improve as much as they had expected. Sales are frustrated because they don’t see how they can influence the product. Users and clients are less than enthusiastic about your products as they don’t get the value they hoped for. Continuing like this is nonsensical.
Then there’s SAFe. It fits the organisation like a glove. Portfolio SAFe has similarities compared to what they are doing today:
Your Product Managers, Enterprise Architects, System Engineers and Product Managers all have a spot in SAFe. The model probably is a mirror of your organisation already. SAFe will adjust the way you create your products, like adding the Agile Release Train. But you don’t have to change your organisation model for SAFe.
Scrum is very disruptive. It has to be because it exists for complex product environments. What will happen is unknown. This is why everything in Scrum is about empiricism: reflection and improvement. SAFe also includes reflection and improvement. But SAFe does it more subtle. As an example, it focuses more on improving current processes instead of searching for alternative ways to reach your goals.
It’s important to note that SAFe doesn’t use Scrum. You can’t choose both frameworks at the same time. SAFe works with ScrumXP. This is an approach influenced by Scrum, but without the relentlessness of true Scrum, as you can read here:
SAFe’s Scrum vs Scrum According To the Scrum Guide — They Are Not the Same
A comparison of two different beastsmedium.com
Sure, SAFe also acknowledges that you can’t predict everything upfront. It has its inspect and adapt opportunities too. But the events with all key stakeholders are less frequent than in Scrum.
If you introduce SAFe to your organisation, you bring in a lot of Lean and Agile practices with it. These can all be of great benefit for the organisation.
When you choose SAFe, you choose a framework that has a meaningful spot for everyone. Everything is well-described. There’s no need for unclarity about how to follow the processes. The whole organisation takes part in the incremental delivery of products. There is room for reflection and improvements.
The caveat
There’s a reason for Scrum to be so disruptive. Scrum exists to tackle the issues that block you from delivering the highest value, however big they are. When an organisation is willing to accept this, Scrum helps to drastically improve the way the teams can deliver their products.
SAFe — being so descriptive — deceptively suits people that like the status quo. Look at how the framework matches many organisation models. This may seem comforting, but the status quo takes the essence out of any Agile approach.
Scrum has Sprint Reviews with the important stakeholders every Sprint (often 1 to 2 weeks). SAFe has similar events every 4 to 10 weeks at the Inspect & Adapt event. SAFe also has Iteration Reviews. But these aren’t the events where the key stakeholders and the team discuss if the product is heading in the right direction and discuss what to do next. So SAFe offers fewer options to adjust course. Adjusting course is a prime reason for Agile frameworks to exist. SAFe is less Agile than Scrum.
Beware of half-baked SAFe
But there’s more. Your organisation failed to embrace Scrum fully. How can you be sure that they treat SAFe differently? Suppose that SAFe fits you like a glove on the surface. This is true for many large organisations. Will you strive to look for improvements? Or will you suffice with your initial version of SAFe? If so, you are set up for half-baked SAFe. Your organisation will be a mere feature factory forgetting to check if these features actually bring value.
SAFe — like any other Agile approach — only works when the organisation is open for reflection and changes. With SAFe you have more formal events to inspect and adapt than Scrum. It is more complex. This means that you need to put more effort into making it work. Otherwise, your adoption of SAFe will lead to an organisational mess. Half-baked SAFe is even worse than half-baked Scrum.
Inspect and adapt
Scrum and SAFe are both Agile frameworks to deliver products of value. They are very different and don’t work together. Both frameworks have their merits. Scrum is suited for complex environments to radically improve or reinvent your processes. SAFe exists for organisations that want to streamline delivery and reflection processes in their current organisation model.
SAFe isn’t an end-state just like Scrum isn’t. Both are frameworks to help you with specific needs. When those needs shift, don’t limit yourself and adapt your way of working to fit your new needs.