While modern organizational structures should institutionalize collaboration and a human-centered focus, the reality often falls short. Why does human-centricity routinely become an afterthought rather than a shared, cross-functional mandate?
Posts tagged Organisation
Seit drei Jahren führe ich SAFe-Artefakte in einer großen öffentlichen Organisation ein. Ich bin zertifizierter SAFe SPC und schätze SAFe als den einzigen praxistauglichen Leitfaden auf dem Markt, der zumindest in Teilen eine konkrete Blaupause für die Transformation großer Organisationen liefert. Aber das heißt noch lange nicht, dass das Framework in meiner täglichen Praxis funktioniert – und vermutlich tut es das in Ihrer auch nicht. Kritik an SAFe gibt es genug. Hier ist mein eigener Blick darauf.
Die Welt ist nicht nur digital
Diese triviale Feststellung ist offensichtlich für Unternehmen, die physische Güter oder Dienstleistungen anbieten, welche die Mitarbeit von echten Menschen erfordern. Das „Produkt“, das hier geschaffen oder verbessert werden soll, kann zum Beispiel ein Beratungsprozess sein, der am Telefon oder am POS stattfindet, die Abläufe für das medizinische Personal im Krankenhaus oder der Verkaufsprozess im Baumarkt. Diese Prozesse sollen gestaltet, entwickelt und in Betrieb genommen, der Erfolg gemessen und der Prozess kontinuierlich verbessert werden.
SAFe bietet im Entwicklungsprozess aber nur den Mechanismus des Agile Release Train (ART) an, der für eine kontinuierliche Softwarebereitstellung konzipiert ist. Die verantwortlichen Rollen haben deshalb auch Bezeichnungen wie „Release Train Engineer“ (RTE), die in der Realität vieler Unternehmen einfach nicht passend sind. Wozu brauche ich einen RTE, wenn mein Produkt ein Gesprächsleitfaden für ein Kundengespräch ist?
Ebenfalls in diesem Kontext völlig unpassend ist das ausführliche und detailgenaue Mandat des „Program Increment“ (PI) Plannings des ART – nicht nur wegen seiner technischen Ausrichtung, sondern auch wegen der Prämisse fester Release-Zyklen. Teams, deren Aufgabe es ist, Problemlösungen für die physische Welt zu entwickeln, arbeiten faktisch in einem kontinuierlichen Fluss und sollten sich eher an einer Kanban-Logik orientieren. Eine Taktung in festen Zeitabschnitten kann für die übergeordnete Planung und Zielsetzung sinnvoll sein, um sie an den Finanzzyklen des Unternehmens auszurichten, wird ansonsten aber als künstlich aufgesetzt und störend empfunden.
Wertschöpfung in der physischen Welt findet immer noch genauso statt wie im Digitalen. Ein vollständiges Rahmenwerk muss Möglichkeiten schaffen, diese hybride Realität in eine Transformation einzubeziehen.
Entkopplung der Produktverantwortung
SAFe ist darauf ausgelegt, die Produktverantwortung auf der Agile-Release-Train- oder Solution-Train-Ebene anzusiedeln (beide sind ein fester Teil der vorgeschlagenen Managementstruktur). Das hat vermutlich den Hintergrund, dass SAFe am Beispiel eines Unternehmens entwickelt wurde, das wenige, aber sehr umfangreiche Softwareprodukte herstellt, bei denen viele Teams an einer einzigen, gemeinsamen Codebasis arbeiten. Wenn mehr als 100 Entwickler benötigt werden, um ein einziges, singuläres Produkt zu bauen, soll es sinnvoll sein, an übergeordneter Stelle eine verantwortliche Rolle zu installieren, die die zugeordneten Teams steuert. So die Hypothese.
Ich will nicht sagen, dass es keine Unternehmen gibt, für die dieser Ansatz funktioniert, aber ich bezweifle es für die meisten. In der Realität bestehen die meisten Produkte aus sinnvoll trennbaren Bestandteilen, für die es jeweils eine (teil-)produktverantwortliche Person geben kann, die eigenverantwortlich operiert. Oder aber das Unternehmen hat ohnehin eine Vielzahl eigenständiger Produkte mit fester Verantwortungszuteilung.
Natürlich müssen sich in jedem Unternehmen alle Akteure abstimmen, eine übergreifende Produktvision entwickeln und diese gemeinsam tragen. Aber graduelle Abstufungen in der Produktverantwortung sind in SAFe schlicht nicht vorgesehen. Auch Ansätze, wie eine solche gemeinsame Vision in einem Umfeld mit vielen dezentralen Verantwortungsträgern entstehen kann, fehlen. SAFe fehlt die Flexibilität, Teams dort Autonomie und Verantwortung zu übertragen, wo sie gebraucht werden.
Wird das System starr nach Lehrbuch angewendet, wertet dies die Teamebene ab und degradiert Product Owner zu reinen Backlog-Verwaltern und Ticket-Schreibern. In der Folge leidet die Produktivität, da die Potenziale der Teams ungenutzt bleiben und das System verliert massiv an Akzeptanz, gerade bei den kompetentesten und engagiertesten Product Ownern und Entwicklern.
Das „Alles-oder-nichts“-Reorganisations-Dilemma
Auch das folgende grundsätzliche Argument sollte eigentlich selbstverständlich sein. Die Entscheidung zur Reorganisation eines Unternehmens hat immer einen Hintergrund. Dieser kann beispielsweise eine organisatorische Sackgasse sein, eine plötzliche Veränderung der Marktsituation, mit der die Organisation konfrontiert ist, oder schlicht der Bedarf und Wille zu einer fortlaufenden Verbesserung, um es erst gar nicht so weit kommen zu lassen. Im ersten Fall kann ein radikaler Umbruch der Organisation notwendig sein, im letzteren wohl eher nicht. Die möglichen Strategien der Organisationsentwicklung reichen dementsprechend von einem „vorsichtigen Umbau“ bis hin zum „radikalen Schnitt“.
Und selbst wenn der Wille vorhanden ist, ist eine vollständige Reorganisation nicht immer machbar. In regulierten Umfeldern oder Unternehmen des öffentlichen Sektors ist die primäre Organisationsstruktur beispielsweise oft gesetzlich vorgegeben. Bestehende Abteilungen können nicht aufgelöst werden, ohne den rechtlichen Rahmen der Institution selbst zu ändern.
Unabhängig davon, welcher Organisationstheorie man anhängt: Sicher ist, dass nicht alle Unternehmen gleich sind und ein starres Konzept für alle keinen Sinn ergibt. SAFe fordert jedoch genau das – eine fundamentale Neuausrichtung der Struktur um den Wertstrom herum. Eine Übergangsarchitektur oder Alternativkonzepte, wie der Aufbau einer Sekundärorganisation bei Erhalt der primären Disziplinarstruktur, sucht man im Framework vergeblich. Damit sollte die buchstabengetreue Anwendung von SAFe für viele Unternehmen von vornherein ein No-Go sein.
Fehlende Nutzerzentrierung und Service Design
Die SAFe-Autoren Dean Leffingwell und Drew Jemilo haben ihren beruflichen Hintergrund im Ingenieurwesen und in der klassischen Softwareentwicklung. Es verwundert daher nicht, dass bestimmte Transformationsaspekte im Vordergrund stehen, während andere zu kurz kommen (um es vorsichtig auszudrücken). Am deutlichsten wird dies für mich beim Thema Design – zugegebenermaßen auch aufgrund meines eigenen beruflichen Hintergrunds.
Zwar werden „Customer Centricity“ und „Design Thinking“ in SAFe als Konzepte erwähnt, bleiben aber bei genauerem Hinsehen unvollständig, missverständlich oder schlicht falsch interpretiert. In SAFe 5 wurde Design Thinking im Kern noch als reine Methode verstanden, um „das Risiko zu minimieren, das Falsche in perfekter Geschwindigkeit zu bauen“, was dem üblichen Verständnis von Design Thinking objektiv einfach nicht gerecht wird. In Version 6 wurde dies zwar oberflächlich korrigiert, indem im Bereich „Agile Product Delivery“ die Werkzeuge Personas, Empathy Maps, Customer Journey Maps und Story Mapping integriert wurden. Doch auch das greift zu kurz und wäre im Kern ohnehin besser mit dem Begriff Service Design beschrieben (wobei die genannten Methoden nur einen kleinen Teil des Service Design abdecken).
Was in SAFe fehlt, ist eine systematische Integration kreativer Arbeit und moderner Anforderungsanalyse auf allen Ebenen des organisatorischen Gefüges, um etwa die erwähnte gemeinsame Produktvision kollaborativ zu entwickeln. Es gibt dann auch weder Ansätze für eine echte siloübergreifende, multidisziplinäre Zusammenarbeit noch einen konkreten Blueprint zur systematischen Einbindung von Endanwendern in den Entwicklungsprozess, wie er auch in der ISO 9241 – 210 definiert ist. Die vorgeschlagenen Methoden wirken etwas hilflos an das bestehende System angedockt, beispielsweise als bloße „Vorbereitung für die PI-Planning-Events“. Das Wort Nutzerzentrierung ist in SAFe am Ende nicht viel mehr als ein Feigenblatt.
Wertdefinition jenseits von operativem Output
Folgerichtig zu dem erwähnten Schwerpunkt auf der technischen Umsetzung hat SAFe auch einen blinden Fleck bei der Definition dessen, was im eigenen Framework (richtigerweise) den Kern der Organisation ausmacht: der Wertschöpfung bzw. dem Wertstrom. Jede Organisation mag ihre eigene Vorstellung davon haben, was einen „Wert“ darstellt, der erzeugt werden soll. Die Sichtweise wird von Unternehmen zu Unternehmen naturgemäß weit auseinandergehen. SAFe bietet hier jedoch nur eine sehr operative Definition an.
In SAFe leitet sich der Begriff „Wert“ (Value) maßgeblich von einem operativen Durchsatz im Stile der klassischen Fertigung ab – vergleichbar mit dem Schneiden, Stanzen, Polieren und Versenden physischer Güter. Das Framework unterscheidet dabei zwischen dem operativen Wertstrom (dem tatsächlichen Erbringen von Dienstleistungen oder Produzieren von Produkten) und dem Entwicklungswertstrom (dem Verbessern der operativen Wertströme). Der Gedanke dahinter scheint zu sein: Wenn die Produktion effizient organisiert ist, entsteht der „Wert“ von allein. Aber welcher Wert entsteht da eigentlich? Ist Wert immer in Geld umzusetzen?
Das Framework bietet keine Modelle, um nicht-monetäre, übergeordnete Effekte wie langfristige Kundenzufriedenheit, gesellschaftlichen Nutzen (Public Value) oder Verbesserungen der Lebensqualität für Menschen in den täglichen Betrieb zu übersetzen. Wie organisiert man ein Unternehmen, das sich zum Ziel setzt, Menschen glücklich machen zu wollen? Oder etwas naheliegender, wie kann ein wichtiger Wert wie “Vertrauen in staatliche Organisationen schaffen” als Wert für ein öffentliches Unternehmen verankert werden?
Wenn eine Organisation sich „um den Wert herum“ strukturieren soll („organize around value“), dann muss das Rahmenwerk auch Werkzeuge anbieten, um diese strategischen, nicht-monetären Werte sauber zu definieren und operativ zu verankern.
Das agile Paradoxon
SAFe ist extrem umfangreich und komplex. Es führt eine Reihe spezialisierter, künstlicher Rollen ein, sieht jedoch keinerlei Anpassungen am eigenen Rahmenwerk vor und dementsprechend auch keine organisatorischen Formate, um solche Anpassungen überhaupt zu planen und durchzuführen. SAFe ist schwer zu erklären, erzeugt eine erhebliche kognitive Belastung und führt auch deshalb zu Widerständen bei genau denjenigen, die es bei der Arbeit eigentlich unterstützen sollte.
Warum die Autoren, die ja nach eigener Aussage Experten für „agiles Arbeiten“ sind, einen derart starren Ansatz gewählt haben, bleibt ein Rätsel. Vielleicht sind Leffingwell und Jemilo am Ende dann doch eher old school Manager als Entwickler. Oder aber – meine persönliche Verschwörungstheorie: Das starre System ist schlicht eine Folge des Geschäftsmodells von Scaled Agile, Inc. mit seinen standardisierten, globalen und zertifizierbaren Schulungspfaden. Es ist zweifellos einfacher, teure Kurse zu verkaufen, wenn das geschriebene Buch die einzige Quelle der Wahrheit ist. Die beste Lösung für Ihr Unternehmen ist es sehr wahrscheinlich nicht.
Wo sind die Alternativen?
Organisationale Agilität erfordert das Gegenteil von SAFe: ein minimalistisches Framework, das Unternehmen die Werkzeuge an die Hand gibt, sich kontinuierlich anzupassen und sich von innen heraus neu zu erfinden. Oder sich aber dann bei Bedarf doch radikal zu ändern. LeSS, Scrum@Scale, Spotify? Ich sehe derzeit nichts, was als Leitfaden für ein großes Unternehmen mit sowohl digitalen als auch nicht-digitalen Abläufen dienen kann. Vielleicht ist es an der Zeit, einen solchen zu entwickeln.
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.