If Not SAFe, Then What?

The credibility of Scaled Agile Framework, aka SAFe, has hit a new low. 

It seems that articles about the ills of SAFe appear daily, often mocking SAFe. Particularly noteworthy was Stefan’s Wolpers’s survey showing a -56 Net Promoter Score (minus 56) for SAFe among the large number of Agile practitioners who follow Wolpers. And then there was the debacle surrounding Paweł Huryn’s article that dismantled the idea that SAFe is agile in any way. The article went viral, and SAFe’s lawyers filed a take-down notice with Medium, removing the article for awhile, but after investigating it, Medium decided that nothing in the article violated terms, and they restored it.

And this appeared recently: the SAFe Delusion website, https://safedelusion.com, which consolidates a lot of the push-back against SAFe from widely followed people in the Agile community.

We ourselves have warned about SAFe. In a talk that I gave at a business agility conference in Madrid two months back, I explained that SAFe is fundamentally a Lean manufacturing approach to software. That has some good aspects to it, but that approach is not going to make you agile anymore than a car assembly line is agile. Lean and Agile are not the same thing.

At Agile 2 Academy, we researched five highly agile companies, and we found that none of them used big complicated processes like SAFe. None of them. In fact, they were not process-centric at all. What they all had in common was that leaders had set the expectation that people solve problems, even if it means “going out of your lane”. And to do that, you are expected to try things before you are 100% sure they will work. In other words, trying things and not succeeding half the time is seen as normal. That expectation that people will try things is what created the psychological safety that Agilists often talk about.

In discovering these things, we had an epiphany: agility arises from how people step outside of their process – not from a process. There is no “agile process”.

Agile companies are agile because their people respond quickly and effectively when tests fail, when designs are found to be wrong, when supply chains break, and when the customer says the product sucks. In these circumstances, the process has broken – you need to stop what you are doing and pivot. And in agile companies, people do that pivoting instinctively. They don’t wait to be told what to do. They don’t wait for a quarterly planning meeting. They don’t file change requests and wait for those to circulate. Instead, they get up and find people, have productive discussions, reach a quick decision on what to try next, and put that in motion – restoring the flow.

But How Do We Do That?

Saying goodbye to the illusory safety of SAFe is scary. SAFe creates a false sense of security by telling you what to do: it defines a whole raft of roles and processes. It is not unlike PMI’s PMP approach to project management: just follow these steps, check those boxes, and wallah – you are set. PMI’s PMP approach was an attempt to replace project management with project administration – something that could be done almost mindlessly by anyone, like a recipe or a paint-by-numbers picture. Except that for highly unpredictable things like software, that approach does not work well.

At Agile 2 Academy, we researched five highly agile companies, and we found that none of them used big complicated processes like SAFe.

To manage software projects well, you cannot be a mere administrator, sitting back and checking boxes: you have to be immersed and issue-focused. And that tendency – that people in leadership roles are immersed and issue-focused – is another common thread that we saw at highly agile companies.

That means that there is no replacement process for SAFe. You cannot unplug it and plug in something else. Instead, you have to grow a culture in which people in leadership roles get immersed, and lead well. It is all about leadership style. And it turns out that most people know that is true: they know it deep inside – they just have forgot, because so much of the narrative in the Agile framework ecosystem has brainwashed us to forget that the Agile Manifesto’s very first value warned us against relying on processes:

Individuals and interactions over processes and tools.

Somehow, SAFe, Scrum, and other frameworks have made us focus on them instead of on individuals and interactions – in other words, on leadership.

Those frameworks are antithetical to the Agile Manifesto. And they are antithetical to agility because they give people “the answer” up front, preventing people from having agency about how to approach their work, and bypassing the learning and collaboration that occurs when people have to decide how they will approach things. The frameworks make people into order-takers, instead of what we find in agile companies – people who take responsibility to solve problems and go “out of their lane”.

What to Replace SAFe With

As I said, there is no plug-in replacement for SAFe. And if you are looking for a quick fix, there isn’t one – sorry, there isn’t. But there is a pathway. To create a culture of the right kinds of leadership, you first have to visualize what the “right kinds” of leadership are. A particularly compelling leadership model is transformational leadership, which has been widely researched.

Perhaps you have read the book Accelerate, by Nicole Forsgren, Jez Humble, and Gene Kim – the last two are often referred to as the “fathers of DevOps”, and Nicole Forsgren is a statistician. She examined the methods used by a large number of tech companies and found very strong correlations between certain behaviors and outcomes. In particular (bold added),

“Our analysis found that these characteristics of transformational leadership are highly correlated with software delivery performance. In fact, we observed significant differences in leadership characteristics among high-, medium-, and low-performing teams. High-performing teams reported having leaders with the strongest behaviors across all dimensions: vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition. In contrast, low-performing teams reported the lowest levels of these leadership characteristics. These differences were all at statistically significant levels. When we take our analysis one step further, we find that teams with the least transformative leaders are far less likely to be high performers. Specifically, teams that report leadership in the bottom one-third of leadership strength are only half as likely to be high performers.”

In other words, what made teams perform well was not having an “Agile process”, but rather having good leaders.

And that applies at all levels of an organization. As blogger Fredrik Carleson recently wrote,

“The problem is that usually, teams are already doing great. The Scrum Team is usually not the problem at all.”

Indeed, one of the reasons for the immense success of the book Team Topologies (which we reference in the Agile 2 book) is that it explains so clearly the importance of the ecosystem that teams exist in: that teams are not all the same, and that a great amount of leadership is needed to make a large number of teams work together.

Note that I said leadership, not process. If you try to make a lot of engineering teams work together using fixed processes, you end up with something like what Boeing does, instead of what SpaceX does. (Comparison of the two here.)

If you are looking for a quick fix, there isn’t one – sorry, there isn’t. But there is a pathway.

It is not that you don’t need process – you do – but process needs to be designed for the task, mostly by the people doing the task, and not imposed from above. I am talking about engineering and development processes, not safety certification processes.

The key is to train and develop people. Leadership is innate for some people, but most people can learn to be better leaders. And some people should not be leaders – it is not their strength.

Once you have a model for the kinds of leadership that you want to have within your organization, you need to upskill people in those. It takes more than classroom training: just like you cannot learn to drive a car purely in a classroom, leadership takes practice, reflection, and more practice. Thus, having a leadership coach to speak to on a regular basis can be really helpful.

The Whole Picture

Of course, we have simplified things to make our main points. The key point is very simple: it comes down to having effective forms of leadership throughout the organization. That is what leads to agility and good performance. That’s the foundation. Without that, you will not operate well. That’s basic. And it transcends any process.

Leadership behaviors become part of the culture – the expectations that people feel for how they respond when things don’t go as expected, which is practically all the time during development. That’s why organizational culture begins with leadership: people in leadership roles largely create the culture, over time.

But people also need knowledge of various kinds: not just knowledge of how to do their tasks, but also knowledge for how to collaborate well, how to link steps together – that is where Lean finally comes into play – and how to manage risk in real time instead of by adding extra steps. Those “patterns for organizing work” need to be in people’s mental toolbox; otherwise, they will use traditional patterns that could slow them down.

The figure below ties it all together: agility arises from behavior – how people respond to the unexpected – which becomes embedded in the culture; and they need to know Lean patterns for managing risk and fine-tuning their work. In other words, they need to be empowered to apply those patterns, situationally, rather than having them imposed from above.

Becoming agile is therefore a learning journey. It is not a process rollout. It is about people learning about leadership models, and receiving coaching on becoming better leaders. It is also about learning agility-promoting behaviors for how to collaborate and work together – behaviors described by Agile 2. And it includes Lean patterns for solving problems, and empowering people to solve their own problems instead of prescribing for them how to do their work – and that is just transformational leadership.

We have defined a roadmap for this kind of transformation. We call it Constructive Agility – a nod to the term Constructive Culture from the Human Synergistics organizational culture model. The roadmap is freely published on our site at agile2academy.com/ca. It defines a pathway for progressively growing an initiative by being intentional about things like culture and agility-promoting behavior from the start. And yes, you can use the roadmap to improve an existing initiative. We are currently using this approach with a range of organizations with great success. Please give it a try, or ask for help if you like. Either way, Constructive Agility is our gift to the business community.