Skip to main content

“Can We Do Scrum And SAFe Simultaneously?”

April 8, 2025

“Can we do 100% Scrum and SAFe simultaneously?” 🤔

This question emerged during a recent Scrum.org Professional Scrum Master Advanced training in Germany 🇩🇪. Some time ago, the company started an Agile transformation and hired me to learn more about Scrum and how it could benefit them.

As part of the training, we used an exercise to clarify the roles of the Product Owner, Scrum Master, and Developers.

The steps of the exercise are:
👉 Form small groups and give everyone cards containing the work and tasks necessary to do Scrum.
👉 Connect the cards with tasks to the roles (SM, PO, Dev, etc) based on a Professional Scrum environment — the way Scrum is intended according to the Scrum Guide
👉 Determine how Scrum is used in your organization. Place dots on the cards that — in your experience — are managed differently.
👉 Discuss the differences, how they impact Scrum, and, more importantly, the underlying values and principles.

During the debrief, many participants noticed that most of the cards related to the Product Owner contained dots. Meaning that someone else is responsible for this work. For example, the Product Owner is NOT responsible for the product budget, roadmap, return on investment, etc. This can result in a powerless Product Owner, dependencies, and bottlenecks. ❌

At this moment, someone shared that they’re also experimenting with SAFe, and the Product Manager is doing most of the Product Owner’s work.

AHA… 😃

They decided to pick the parts from SAFe that they considered valuable. Interestingly, they chose not to use RTEs because they expected Scrum Masters to step up and broaden their responsibilities. But because of the product’s complexity, they wanted a Product Manager (bigger picture) and a Product Owner (close to the team, more detailed work).

During the remainder of the training, we frequently discussed the possibilities of doing 100% Scrum and SAFe simultaneously.

My answer to this question is: you can’t. ❌

You can’t do 100% Scrum and SAFe simultaneously. It requires tradeoffs.

Does this mean it’s wrong? Not necessarily. I’ll be the last to claim you always need to do 100% Scrum, and despite not being a SAFe supporter, I also don’t despise it. I can see the value of SAFe for some organizations.

I would encourage mindfulness of the tradeoffs’ consequences. What is the impact, and is it worth doing or causing damage? 🤷‍♀️

In this example, the organization is doing just fine. They’re on a journey, running various experiments to see what works for their context. They don’t limit themselves to one framework or method and are open-minded to see what benefits them. Awesome. 😎

How would you answer this question?
What is your experience?


What did you think about this post?

Comments (2)


Wasif Mehdi
03:47 pm April 8, 2025

Bottomline you can't do SAFe without Scrum. So if an organisation is leveraging SAFe they will need to setup their scrum teams who will conduct work and deliver value leveraging scrum. In other words in a SAFe organisation scrum will be running at the Team level. That said, ofcourse all businesses should look to refine the frameworks (within certain thresholds) to make them work for their particular contexts.

On the flip side if the organisation is already using scrum it doesn't necessarily need to use safe assuming it does not need to scale their Lean-Agile practices.


Tom
03:09 am April 19, 2025

Before I learned SAFe, I always regarded it as a sacred existence. After I obtained SPC and implemented teaching to achieve 600+,

I want to tell everyone what we understand about SAFe in our Chinese environment:

1) The essence of SAFe is still a bureaucratic machine. Some middle and senior managers of large organizations or enterprises have found their own position in SAFe smoothly, and continue to practice the long-term "conservative" and "one-handed" overbearing behavior and bureaucratic management thinking mode;

2) SAFe PI Roadmap cannot follow the maximum 4-week cycle like Scrum. PI Roadmap is usually based on "portfolio level" or "solution level" and extends PI Roadmap to 1-2 years. This is a return to the old road of highly planned and highly controlled predictive project management. This is not agile, and it runs counter to the original intention of "adaptability" and "responding to changes".