For three years, I have been introducing SAFe artifacts in a large, public organization. I am a certified SAFe SPC and appreciate SAFe as the only practical guidebook on the market that provides, at least in part, a concrete blueprint for the transformation of large organizations. But that does not mean that the framework works in my daily practice – and presumably it does not in yours either. There is a lot of criticism of SAFe. Here is my view on it.
The World Is Not Only Digital
This trivial observation is obvious for companies producing physical goods or services that require the involvement of real people. The „product” to be created or improved here can be, for example, a consulting process that takes place on the phone or at the POS, the procedures for medical personnel in a hospital, or the sales process in a hardware store. These processes are to be designed, developed, and put into operation, the success measured, and the process continuously improved.
In the development process, however, SAFe only offers the mechanism of the Agile Release Train (ART), which is designed for continuous software delivery. The responsible roles therefore also have designations like „Release Train Engineer” (RTE), which are simply not appropriate in the reality of many companies. Why do I need an RTE if my product is a conversation guide for a customer interview?
Also completely inappropriate in this context is the detailed and precise mandate of the „Program Increment” (PI) planning of the ART – not only because of its technical orientation, but also because of the premise of fixed release cycles. Teams whose task is to develop problem solutions for the physical world factually work in a continuous flow and should rather orient themselves toward a Kanban logic. A cadence in fixed time intervals can be useful for high-level planning and goal setting to align them with the financial cycles of the company, but is otherwise perceived as artificially imposed and disruptive.
Value creation in the physical world still takes place just as it does in the digital. A complete framework must create opportunities to include this hybrid reality into a transformation.
Decoupling of Product Responsibility
SAFe is designed to locate product responsibility at the Agile Release Train or Solution Train level (both are a fixed part of the proposed management structure). This presumably has the background that SAFe was developed using the example of a company that produces few but very extensive software products, where many teams work on a single, shared codebase. If more than 100 developers are required to build a single, singular product, it is supposed to be useful to install a responsible role at a higher level to manage the assigned teams. So goes the hypothesis.
I do not want to say that there are no companies for which this approach works, but I doubt it for most. In reality, most products consist of meaningfully separable components for which there can be a (partially) product-responsible person who operates independently. Or the company already has a variety of independent products with fixed responsibility allocation.
Of course, in every company, all actors must coordinate, develop an overarching product vision, and bear it together. But gradual nuances in product responsibility are simply not provided for in SAFe. Approaches on how such a shared vision can emerge in an environment with many decentralized decision-makers are also missing. SAFe lacks the flexibility to transfer autonomy and responsibility to teams where they are needed.
If the system is applied rigidly according to the textbook, this devalues the team level and degrades Product Owners to mere backlog administrators and ticket writers. As a result, productivity suffers because the potentials of the teams remain unused, and the system massively loses acceptance, especially among the most competent and committed Product Owners and developers.
The „All-or-Nothing” Reorganization Dilemma
The following fundamental argument should also actually be self-evident. The decision to reorganize a company always has a background. This can be, for example, an organizational dead end, a sudden change in the market situation faced by the organization, or simply the need and desire for continuous improvement to prevent things from getting that far in the first place. In the first case, a radical upheaval of the organization may be necessary; in the latter, probably not. The possible strategies of organizational development accordingly range from a „cautious restructuring” to a „radical cut”.
And even if the will is present, a complete reorganization is not always feasible. In regulated environments or public sector enterprises, for example, the primary organizational structure is often legally prescribed. Existing departments cannot be dissolved without changing the legal framework of the institution itself.
Regardless of which organizational theory one adheres to: What is certain is that not all companies are the same and a rigid concept makes no sense for everyone. SAFe, however, demands exactly that – a fundamental realignment of the structure around the value stream. One looks in vain in the framework for a transition architecture or alternative concepts, such as the creation of a secondary organization while maintaining the primary disciplinary structure. Therefore, the literal application of SAFe should be a no-go for many companies from the beginning.
Missing User-Centricity and Service Design
The SAFe authors Dean Leffingwell and Drew Jemilo have their professional background in engineering and classical software development. It is therefore not surprising that certain transformation aspects are in the foreground while others fall short (to put it mildly). This becomes clearest to me when it comes to design – admittedly also due to my own professional background.
Although „Customer Centricity” and „Design Thinking” are mentioned as concepts in SAFe, upon closer inspection they remain incomplete, misunderstood, or simply misinterpreted. In SAFe 5, Design Thinking was fundamentally still understood as a pure method to „minimize the risk of building the wrong thing at perfect speed,” which objectively simply does not do justice to the usual understanding of Design Thinking. In version 6, this was corrected superficially by integrating the tools personas, empathy maps, customer journey maps, and story mapping into the „Agile Product Delivery” area. But even that falls short and would fundamentally be better described by the term Service Design anyway (whereby the mentioned methods only cover a small part of Service Design).
What is missing in SAFe is a systematic integration of creative work and modern requirements analysis at all levels of the organizational fabric, for instance to collaboratively develop the mentioned shared product vision. There are also neither approaches for true cross-silo, multidisciplinary collaboration nor a concrete blueprint for the systematic involvement of end users in the development process, as is also defined in ISO 9241 – 210. The proposed methods seem somewhat helplessly attached to the existing system, for example as a mere „preparation for the PI planning events.” The word user-centricity is in the end not much more than a fig leaf in SAFe.
Value Definition Beyond Operational Output
Consequently, corresponding to the mentioned focus on technical implementation, SAFe also has a blind spot in the definition of what (rightly) constitutes the core of the organization in its own framework: value creation or the value stream. Every organization may have its own idea of what constitutes a „value” to be generated. The perspective will naturally diverge widely from company to company. SAFe, however, offers only a very operational definition here.
In SAFe, the term „value” is significantly derived from an operational throughput in the style of classical manufacturing – comparable to cutting, stamping, polishing, and shipping physical goods. The framework distinguishes between the operational value stream (the actual provision of services or production of products) and the development value stream (the improvement of operational value streams). The thought behind it seems to be: If production is efficiently organized, the „value” arises on its own. But what value actually arises there? Is value always to be converted into money?
The framework offers no models to translate non-monetary, high-level effects such as long-term customer satisfaction, public value, or improvements in the quality of life for people into daily operations. How do you organize a company that sets itself the goal of wanting to make people happy? Or somewhat more obvious, how can an important value like „creating trust in state organizations” be anchored as a value for a public enterprise?
If an organization is to structure itself „around value” („organize around value”), then the framework must also offer tools to cleanly define and operationally anchor these strategic, non-monetary values.
The Agile Paradox
SAFe is extremely extensive and complex. It introduces a number of specialized, artificial roles, but provides no adaptations to its own framework and, accordingly, no organizational formats to plan and execute such adaptations in the first place. SAFe is difficult to explain, creates a significant cognitive load, and therefore also leads to resistance among exactly those whom it is actually supposed to support in their work.
Why the authors, who by their own account are experts in „agile”, chose such a rigid approach remains a mystery. Perhaps Leffingwell and Jemilo are, in the end, rather old school managers than developers. Or else – my personal conspiracy theory: the rigid system is simply a consequence of the business model of Scaled Agile, Inc. with its standardized, global, and certifiable training tracks. It is undoubtedly easier to sell expensive courses when the written book is the only source of truth. Good for them, but very likely not the best solution for your company.
Where Are the Alternatives?
Organizational agility requires the opposite of SAFe: a minimalist framework that gives companies the tools to continuously adapt and reinvent themselves from within. Or, if necessary, to change radically after all. LeSS, Scrum@Scale, Spotify? I currently see nothing that can serve as a guidebook for a large enterprise with both digital and non-digital operations. Perhaps it is time to develop one.