How Agile 2 Compares to SAFe

The Agile community is deeply divided about the Scaled Agile Framework, aka “SAFe”. I recall when SAFe was introduced, parts of the Agile community piled on, claiming that SAFe was “un-Agile”, and it was clear that many (most?) of those making that claim had not actually read the SAFe material.

This is natural, because SAFe was new, and it presented a threat to the status quo. It was “the new kid on the block”, and since Agile is, in effect, commercial territory, the block is carved up into the various tribes (gangs?) that own those parts. Woe to the newcomer.

I am not writing here to advocate for SAFe. I am not against SAFe nor am I for it. To me it is a set of ideas, and I welcome all ideas. I like to take ideas, and incorporate them into my set of mental models, and then decide what to do, which might look like none of the ideas that I have taken in, but surely is influenced by them. I am very familiar with SAFe though: I have been part of SAFe initiatives, and I interviewed Dean Leffingwell at length in 2015.

What SAFe Really Is

SAFe is a set of ideas about how to organize large initiatives. That’s it. And that is quite welcome if you have to set up a large initiative. Ideas are good, right? There are other ideas too: some of my favorites come from Larman and Vodde’s 2010 book, Practices for Scaling Lean & Agile Development. I like that book because the authors make it clear that they are just offering a set of ideas.

There are many others too, but let’s not go down that tangent. SAFe is just a set of ideas for how to decompose the many work streams that must exist when building something big and complex - like a ship or a satellite. When one is building real products that consist of real hardware, many with embedded software, and with many vendors involved supplying the various components or assemblies, you had better have things well organized, and don’t just expect that teams will self-organize. And in such a situation, the big challenges are not at the team level: they are at the inter-team and ecosystem level. SAFe also contains ideas pertaining to managing portfolios of multiple products.

Some of SAFe’s ideas include,

• Dividing the work into separate “release trains” - which SAFe now refers to as “pipelines” in order to align with DevOpv vernacular.
• Defining various roles, including System Architect/Engineer, Product Manager, and so on.
• Defining various practices and meeting types in which the various teams and roles collaborate and make decisions.

That is all good food for thought. Of course - at least in my experience - one cannot really take that and just apply it like a template. The situation in each organization, and for each product, is always unique. Perhaps the role of “System Architect” needs to be a little different in your organization, due to the fact that some teams are distributed. Or perhaps you have some particularly brilliant engineers who need a special role because it was their inspiration behind the product in the first place, but none of them is a particularly good leader.

So it always depends. One needs to be thoughtful about how one arranges things, and one needs to keep a close eye, and always be ready to adjust. That applies whether one is designing a product or designing the ecosystem in which the product will be designed and built.

What Else Is There?

There is a lot. In fact, one of the big things that tends to be missing from Agile frameworks and conversations is almost taboo: the topic of leadership. In the words of Nicole Forsgren, Jez Humble, and Gene Kim,

“Why have technology practitioners continuously sought to improve the approach to software development and deployment as well as the stability and security of infrastructure and platforms, yet, in large part, have overlooked (or are unclear about) the way to lead, manage, and sustain these endeavors?. . .we must improve the way we lead and manage IT.”

They used the Agile “dirty word”: “manage”. Agilists don’t like that word, because it conjures up an antithesis of “self organizing team”. In the standard Agile narrative, Agile teams do not need a manager - current thinking is that they should be “self managing”.

But people who build real things at scale know better. Managers are essential, and SAFe is very comfortable with the presence of managers in the ecosystem. In fact, it relies on them to set up the teams and get the overall framework in place.

Agilists are right to be afraid of managers, because we have all had bad managers. In fact, a bad manager is worse than no manager at all. Given that, maybe we should just avoid the whole problem and agree, No Managers!

But that won’t work, because to scale, you need organizers; and self organization at scale works quite poorly. What happens is that leaders emerge, and those leaders are quite often toxic power-seeking popularity contest winners - not servant leaders.

So we need a system for selecting the right managers, but how?

And that is where we arrive at the inescapable place that all organization roads lead to: culture. An organization’s culture includes its culture of leadership, and what styles of leadership tend to be rewarded and groomed.

If the organization promotes toxic autocratic leadership - what organization culture experts Robert Cooke and Janet Szumal refer to as “Aggressive/Defensive” and “Passive/Defensive” Cultures - then the organization will likely have trouble no matter what framework it uses. And today these two researchers can provide a huge repository of data spanning 50 years to back that up.

But what is good leadership? The Agile community often talks about servant leadership, even though the community generally misrepresents what servant leadership actually is. But that’s another tangent I don’t want to go down.

Here is where Agile 2 comes into the picture. Agile 2 examines the range of issues that arise when humans try to accomplish things together, particularly at scale. It then examines if standard “Agile narratives” have answers for those issues, and if so, are those answers viable? And if not, what ideas are potentially viable? And if standard Agile narratives do not have an answer for the issue, then Agile 2 adds its own ideas.

One of the biggest gaps in the set of standard Agile narratives pertains to leadership: the community generally has very narrow or impractical ideas about what kinds or what amounts of leadership are needed. For example, a colleague who is SVP of Platform Engineering and Cloud at a Fortune 500 company recent wrote to me,

...the balance between autonomy and technical strategy is simply broken…

He then went on to lament about how teams are always trying to do things that are counter to the organization’s technical strategies, and they use Agile as an excuse, claiming that they should be autonomous. It is a chronic problem for him, because he has organization-wide strategic things he is trying to accomplish, but the teams tend to think locally about their own immediate needs.

This is where technical leadership comes into play. I don’t know how he runs his shop, but what organizations need is a technical leader who can,

• Explain enterprise technical strategies to people, and get the word out.
• Groom program level technical leads, and make them aware of the strategies; in fact, invite them to collaborate about those strategies.
• Make sure that teams have tech leads who know the enterprise strategies.
• Create a culture of dialectic dialog in which teams discuss issues at all levels - at the team level, the cross-team level, and above.

There is more to it than that, but all this is easier said than done, and a large part of Agile 2 consists of ideas related to leadership’s many kinds and styles and how they come into play when building complex things at scale. Agile 2 is not a framework: it does not say “do this, then do that”; but it calls attention to the problems that tend to arise and what is needed to address or prevent those. It is up to the leader to put those ideas together into a strategy.

Back to SAFe

You might be able to see why Agile 2 ideas might be helpful for a SAFe initiative. SAFe gives you process ideas, but it does not say much about behavior or culture. But one needs both. One needs tangible practices to establish momentum and to get things organized quickly; and one needs to create the right kinds of behavioral and cultural norms. SAFe and Agile 2 therefore complement each other.

Conclusion

SAFe is a set of practices and patterns for organizing people and processes. Agile 2 is a set of models and ideas about human behavior in groups, especially when working on complex things: how people collaborate best, what kinds of leadership they tend to need in different situations, how people need to be treated - especially given that people vary a great deal - how to grow people’s abilities, and much more. We call it “grown up Agile”. It cannot fail to help any SAFe initiative to operate better.