This blog is not about why SAFe is or isn’t a good framework. I know there are a lot of opinions about SAFe, especially in the Scrum community. Whatever your opinion is about SAFe, it has conquered a place in organizations.

Looking at the 15^th “State of Agile” report, 66% of the people who answered the survey implemented Scrum (or something they call Scrum).

When looking at scaling frameworks, 37% uses SAFe. Followed by Scrum of Scrums/Scrum@Scale with 9%. That is a difference of 28 percent points between the number 1 and number 2.

Around me I hear some companies switching from Scrum to SAFe. And not every company needs to be scaling. Remember the 1^st rule of scaling: “Don’t scale!”. It’s often better not to scale up your teams, but to scale down the dependencies between teams. The second rule of scaling: “Don’t scale it till you made it.” Don’t scale if your teams haven’t mastered Agile working on a team level yet. You’ll only add complexity and making the chance of success even smaller.

Taking a look at Scrum, Scrum doesn’t describe beyond the team level. The Scrum Guide states that one of the responsibilities of the Scrum Master is to serve the organization in leading, training and coaching in its Scrum adaptation and planning and advising Scrum implementations within the organization. How that’s done and what the role is going to be of people and how the organization is going to look like isn’t shown. And that’s ok, because the goal of the Scrum Guide is not to be prescriptive. Aligning business and development can be hard for some organizations. Also, some layers of management have a hard time with Scrum. Scrum advocates putting the responsibility as low as possible in the organization. When possible, in the Scrum Teams: ”The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They [the Scrum teams] are structured and empowered by the organization to manage their own work.” (Scrum Guide 2020). If you read the Scrum Guide, without knowing the soul of Scrum, one could read “Just let the Scrum Teams do their thing and everything will be ok. We don’t need people like managers anymore.” So what place does management have in this? In a LinkedIn post I saw 2 questions I’ve heard managers ask before:

“What will people think of me if I’m not constantly visible?”

“Will my employer see my value if I’m not managing people?”

Also I’ve heard remarks like:” I’m loosing the connection with the teams. How do I keep connected with them?”

Looking at SAFe, even “Essential SAFe” offers an organizational view beyond the Scrum Teams. This makes the position for “Lean-Agile Leadership” more clear than within Scrum. Yes, there are paths where the role of Agile Leadership is made clear, Think about the Professional Agile Leadership path, but just looking at the Scrum Framework, as described in the Scrum Guide, it doesn’t explicit cover leadership (besides the leader who serves in the role of a Scrum Master). Finding your place in the organization and how to grow as an Agile Leader is up to you to find knowledge about from other sources. Think about books like “Extreme Ownership” by Jocko Willink and Leif Babin and “The Serving Leader” by Ken Jennings and John Stahl-Wert or the book “Creativity, inc.” by Ed Catmull. Those are not books about how to be a leader in an organization where Scrum is used, but they help you create a mindset about leaders who serve. What do the teams need to grow and how can you, as a leader, help them in their journey. And let a Scrum Master help you develop as an Agile Leader.

SAFe covers the essence of what the creators think is needed from Lean-Agile Leadership in their framework. It covers the dimensions “Mindset & Principles”, “Leading by Example” and “Leading Change”. It gives a more clear view on what is expected from leadership in the organization. That clear view is what people often helps with embracing a framework. When an organization changes, giving some clarity about your place in the new organization helps take away uncertainty. If you look at the organizational structure, Scrum looks different to an organization. The traditional “Taylor” like, hierarchical, organization is often shown as less suitable and there is more preference for a more organic, network structure.

Where SAFe places the structure for organizing work around values on top of the existing traditional structure. In this way, SAFe is safe (pun intended). You know your spot in the organization is safe and there is no need for a complex reorganization.

(source: https://www.scaledagileframework.com/organize-around-value/)

That feeling of security, where everyone knows what their place in the new organization is, is a reason why SAFe is getting more and more popular. In a random search in 24 job offers for Scrum Master, 33% asked knowledge about SAFe. Also, according to the “State of Agile” reports, the percentage of organizations using SAFe keeps growing:

The percentage of organizations using SAFe, measured since the 9^th annual “State of Agile” survey.

Is Scrum that much different from SAFe?

If there is one thing the Scrum community can learn from the SAFe community is how do you get your message across. A lot is about communication. While SAFe communicates clearly about what is expected from the organization around the teams, Scrum leaves that more open and is less prescriptive. This makes a transition to Scrum within an organization (outside the software development teams) harder. It asks flexibility and an open mindset from everyone involved. And that isn’t always easy. Especially when during this transition, some traditional rules are still in play. Think about a manager who needs to put the responsibility for delivering value at team level, but when it goes wrong it’s his/her head on the chopping block. That is a scarry thing. There must be enough trust to let go and not keep managing the teams. But switching to leading and coaching them to grow.

But that same trust needs to be there with SAFe. Take a look at the Growth Mindset. “I like to try new things” and “Failure is an opportunity to grow” are two examples of a Growth Mindset that is advocated in SAFe. This doesn’t sound like “Everything is staying the way it is”.

Also think about one of the core values of SAFe “Alignment”. The ScaledAgileFramework.com site states: “Alignment, however, does not imply or encourage top-down command and control. Alignment occurs when everyone is working toward a common direction. Indeed, Alignment enables empowerment, autonomy, and Decentralized Decision-making, allowing those who implement value to make better local decisions.” So here also the teams should be empowered to make the right decisions. And management supports the teams in doing so.

And there are more examples on organizational and management level where the thoughts behind Scrum align with SAFe.

Once again, I’m not stating SAFe is better than Scrum or Scrum is better than SAFe. I think there are situations where Scrum is a better fit and there will be situations where one can better implement SAFe (or LeSS, or Nexus, or Kanban). Just as long as the goal isn’t using an Agile framework, but goals like responding fast to change by inspecting and learning from the value you have delivered to users and adapting with the new knowledge you’ve gathered in mind