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.
I know SAFe and the corresponding courses from the Scaled Agile Institute (SAI) from several perspectives: in the beginning, I myself was a sceptical participant in courses such as Leading SAFe or Implementing SAFe; later, as a SAFe Program Consultant (SPC), I helped the Swisscom organisational areas to introduce agile methods (some of which were at least SAFe oriented). And I also taught SAI courses for two years.
Insight in brief
- SAFe is controversial, but much better than its reputation.
- SAFe is undoubtedly the most complex, heavyweight and restrictive of the major approaches to scaling Agility.
- SAFe should by no means be thought of simply, and without some reflection, as a blueprint. It may also be a suitable intermediate step in some companies that are working on their agility.
- Companies that understand the framework as being one tool(box) of many, and a temporary solution, can benefit from SAFe.
I remember it well: at the beginning I had big reservations about SAFe. The model seemed to me unnecessarily complicated and difficult to communicate, insufficient in content and some aspects fundamentally contradicted my understanding of the agile principles. In short: SAFe seemed like methodical ballast to me. (An assessment that some loud voices in the community express.)
I have, admittedly, retained a critical basic attitude towards SAFe and the SAI. In the meantime, however, I no longer see SAFe as ballast, but primarily as a treasure trove of proven patterns (from the world of Agility and Lean Production, but also traditional approaches such as RUP), which are arranged in a logical context.
Is SAFe above criticism? Certainly not. There are three points in particular that I would like to address and compare with my assessment:
"Our company will not become better with SAFe (more profitable, customer-oriented, innovative, ... )."
This assessment is often based on a fundamental misunderstanding: that SAFe is primarily aimed at improving the operating business. SAFe is a framework for product development. This can easily be overlooked. Because, for example, SAFe is based on an organisational transformation on several levels - from the development team to the management. Because it talks about "Value Streams", but it almost always means "Development Value Streams" - not operational value-creation chains. Because SAFe itself promises "dramatic increases in employee engagement, better profitability and jobs with more productivity, inspiration and fun". And of course, because nowadays (IT) product development is the basis for the core business of almost all companies.
However: product development is very rarely the core business itself. In the enthusiasm for supposedly simple solutions (such as an "Agile Transformation") this fact is easily ignored and false expectations are raised.
- Take the case of a technology producer who has no idea how to deal with competitors in the digitalisation process; SAFe will only help if they also demonstrate courage to innovate.
- A bank needs more than just SAFe 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 does not need to introduce SAFe: instead, it needs to change systemically to promote the intrinsic motivation of its employees.
An agile product development often makes a company's fundamental problems more obvious. And improvements in the development process may also have a positive impact in some operational areas. Aspects of SAFe can be extremely valuable tools when used correctly. But to achieve this, we also need to keep expectations realistic and be aware that it takes more than SAFe to solve problems in the operating business and in the overall system.
"SAFe is unnecessarily complicated."
For me, this criticism is understandable. Unfortunately, SAFe nomenclature is very inconsistent. The meanings of individual terms (from "Product Management" through "Value Stream" to "Project Management Office") often contradict other, established models. And the "Tailoring Down" approach requires expert knowledge of the whole model just to be able to determine what can and cannot be omitted in an individual case.
Even basic courses like "Leading SAFe" and the simplest certification as "Certified SAFe Agilist (SA)" assume knowledge of all four levels - while the "Value Stream" level is only ever really relevant for a small part of very large companies.
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. In my opinion, SAFe can and must improve its didactics considerably in order to lower the hurdle to deployment.
"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. I understand the claim well and from an agile point of view it is catchy. 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. The creation overnight of completely autonomous teams is simply not conceivable. Very complex solutions are often not easy to take apart.
I do not see SAFe's approach of "Nothing beats an Agile Team except a Team of Agile Teams" as 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 seems important to me not to misunderstand SAFe as a perfect target. The feasible reduction of dependencies should be continuously and vigorously promoted, and the framework itself should be regularly reviewed and adapted with regard to its suitability for the respective organisation.
Frameworks are not blueprints that you just have to lay on companies, and voilà - success is guaranteed. SAFe is no exception. As I said at the beginning, SAFe is a treasure chest. But the road to recovery is different for every organisation, it is hard work and not without risk. The value of each SAFe element is not immediately apparent to everyone. Some things can with confidence be left behind as ballast after the first test - to perhaps come back to them later.
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? Have a look at our courses.