SAFe – Agile Treasure Chest or Ballast?

Swisscom, BMW, Deutsche Bahn, TomTom and many other companies use the Scaled Agile Framework (SAFe®). There is great demand for training and consulting on scaling agility, but not all expectations of the framework are fulfilled.

This post was originally written by Johannes Kling about SAFe version 4.0. Since then, SAFe has been further developed and some of the criticism voiced at that time has been taken into account. To reflect the latest state of development, the post has been revised accordingly, most recently by Romano Roth and Johannes Kling jointly.

Both of them know SAFe and the relevant courses run by the Scaled Agile Institute (SAI) from several perspectives. Initially, they took part in courses such as Leading SAFe or Implementing SAFe; they help companies to implement agile methods (at least some of which are oriented towards SAFe) and provide training on agility, including SAFe.

We, Romano and Johannes, remember it well: at the beginning we had big reservations about SAFe. The model at that time seemed to us unnecessarily complicated and difficult to communicate, and insufficient in terms of content. Some aspects fundamentally contradicted our understanding of the agile principles. In short, SAFe seemed to us like methods-dominated ballast. (An assessment that some loud voices in the community also express.)

Admittedly, we have both retained a critical attitude towards SAFe and the SAI. In the meantime, however, we no longer see SAFe as ballast, but primarily as a treasure chest of proven samples (in Agility, Lean Production and Lean Startup, but also in traditional approaches such as RUP) that are arranged in a logical context.

Is SAFe above criticism? Certainly not. There are a few points in particular that we would like to address and compare with our assessment:

"Our company won't become better with SAFe (more profitable, more customer-oriented, more innovative, ...)."

For a long time, SAFe was primarily a framework for product development with lean-agile methods. When SAFe versions prior to 5.0 referred to 'Value Streams', they almost always meant 'Development Value Streams' – not Operational Value Streams that directly influence business value. 
In the enthusiasm for supposedly simple solutions (such as an 'Agile Transformation'), it was easy for this fact to be ignored and false expectations to be created. 

• Take the case of a technology manufacturer without any idea of how to deal with competitors in the digitalisation process; agile development can only help if the manufacturer also shows the courage to innovate.
• A bank needs more than just scaled agility to strengthen the customer orientation of its business organisation and make its offerings more attractive.
• A public authority that wants to improve its attractiveness as an employer in the marketplace doesn't need to introduce 'Essential SAFe': instead, it needs to change systemically to create space for the intrinsic motivation of its employees, to then benefit from those employees.

With version 5.0, SAFe has taken these points on board and expanded its model considerably. Since then, SAFe (in the 'Portfolio' and 'Full' configurations) has focussed on pursuing Business Agility. For example, it places additional emphasis on Organisational Agility and a Continuous Learning Culture. Accordingly, it has incorporated further methods, such as the analysis of operational value chains, or the Objectives and Key Results method (OKR), and adapted elements from Eric Ries' 'Lean Startup' and the Business Model Canvas by Alexander Osterwalder / Strategyzer. SAFe is based – for the whole company – on the Learning Organisation, Innovation Culture and Relentless Improvement and focusses on the process organisation instead of the organisational structure.

In this respect, SAFe has become even more ambitious in the latest stages of expansion and promises even more than in the past; in addition, it offers a variety of valuable new tools that can be leveraged throughout the organization, allowing the use of SAFe to better fulfil its value proposition.

"SAFe is unnecessarily complicated."

This criticism was and is understandable. The inconsistency of SAFe nomenclature has long been an obstacle. Occasionally, the meaning of individual terms contradicted other, established models, so not everyone will find themselves within the SAFe definition of 'product management'. Some things have improved in the newer versions, however: for a long time, 'Value Stream' was very unclear and misleading and had multiple connotations, including that of a scaling level. (This is now called 'Large Solution'.) The absurdity of a 'Project Management Office' completely contradicted its own teachings – fortunately, the term has since been dropped. 

The 'Tailoring down' approach has been retained. It requires a knowledge of the whole model just to be able to determine what can and cannot be omitted in an individual case. Accordingly, even basic courses such as 'Leading SAFe' and the most basic certification as 'Certified SAFe Agilist (SA)' assume a knowledge of all levels and configurations.

All of this requires a lot of energy from everyone involved in the project for the task of dealing with the methods and processes – contradictory in an approach that sees itself as agile. Didactically, SAFe has improved significantly, but the barrier to using it is still high. So the following principle is therefore important: don't scale if you don't really need to!

"A scaled agile organisation should rely on independent teams. SAFe is taking the wrong approach by cementing interdependencies between teams."

The much-cited 'Spotify Model' takes the approach of using teams, preferably autonomous, that can independently implement end-to-end solutions. LeSS also clearly prefers autonomous, added-value-oriented Feature Teams to Component Teams. From an agile perspective, it's a catchy claim. For the reality in many organisations, however, it falls short of the mark. Companies have often developed very traditionally over years and even decades. Their teams have to deal with many dependencies on legacy systems, for example. Very complex solutions are often not so easy to take apart, and creating completely autonomous teams overnight is simply not feasible.

The SAFe approach of "Nothing beats an Agile Team except a Team of Agile Teams" is definitely not a universal truth. But in many cases the 'Team of Agile Teams' will be the means of choice – or at least a necessary evil. It is important not to misunderstand SAFe as the perfect target picture. The feasible reduction of dependencies should be continuously and vigorously promoted, and the framework itself should be regularly reviewed with regard to its suitability for the respective organisation – and adapted as necessary.

SAFe completely ignores the operational aspect.

In fact, you might think that SAFe is completely focussed on delivery, but that description is too limited. SAFe defines the Continuous Delivery Pipeline not just as CI/CD (Continuous Integration / Continuous Deployment) but also adds Continuous Exploration in front and Release on Demand behind. This creates a continuous pipeline that covers all aspects from the idea through to production. Thanks to the all-embracing DevOps approach with the 16 activities in the four dimensions, you have an end-to-end process including operation, which starts with the customer and ends with the customer. .

No blueprint

Frameworks are not blueprints that you just have to lay onto companies, and voilà – success is guaranteed. SAFe is no exception. As we said at the beginning, SAFe is a treasure chest. But the road to recovery is different for every organisation; it means hard work and is not without risk. The value of each SAFe element is not immediately apparent to everyone. After the first test, some things can with confidence be left behind as ballast – perhaps to return to them at a later moment.

What challenges do you face when it comes to scaling Agility? And: how do you view the suitability of SAFe for your organisation?

Would you like to find out more about SAFe? Attend the courses at the Zühlke Academy.