Kernbotschaften
- Transformation scheitert selten an Scrum, OKRs oder SAFe – sondern daran, dass das Betriebssystem der Organisation (Entscheiden, Lernen, Eskalieren, Priorisieren) unverändert bleibt.
- Erfolgreiche Transformationen folgen Mustern – aber keine dieser Erfolgsgeschichten lässt sich als reines Skalierungsframework kopieren; entscheidend ist die zugrunde liegende Systemlogik.
- Organisationen sind als komplexe soziale Systeme zu verstehen. Daher braucht es eine Ebene unterhalb von Projekten und Programmen: ein Transformations‑Betriebssystem aus einem 2‑Cycles (einem systemischen Innen‑Außen‑Modell für Weltbild und Struktur), systemischen Archetypen und kognitiven Biases. Dieses Betriebssystem ist der geistige Unterbau einer Transformation und liefert die Basis für mein Buch, Arbeitstitel: „Agile Transformation Navigator“.
Einstieg: Warum sich Transformation oft schwer anfühlt
Vielleicht kennst du das: Ihr startet mit Energie in „die Transformation“.
Es gibt einen Kick-off, eine Roadmap, ein Programmteam. Vielleicht OKRs. Vielleicht ein Skalierungsframework wie SAFe. Am Anfang fühlt es sich an, als hättet ihr endlich einen Plan.
Und dann zieht der Alltag euch zurück in alte Muster: Entscheidungen stauen sich, Prioritäten springen, Teams werden „agil“, aber nicht freier. Je mehr du loslassen willst, desto öfter musst du wieder eingreifen. In HR/OE oder Beratung erlebst du saubere Workshops, volle Templates – aber die Organisation lernt nicht wirklich schneller.
In diesen Situationen liegt es selten am Toolset allein.
Und auch nicht nur an „Mindset“ oder „mehr Change“.
Die eigentliche Baustelle liegt eine Ebene tiefer: bei der Art, wie eure Organisation als komplexes soziales System ihre Entscheidungen produziert, sich schützt und erneuert – also in ihrem Betriebssystem.
Warum Projektlogik und Frameworks an eine Grenze stoßen
Transformationen werden schnell in Projektlogik gegossen: Programme, iterationen, Workstreams, „Adoption“-KPIs. Das gibt Struktur und das Gefühl von Steuerbarkeit – gerade in großen Organisationen.
Aber Projektlogik bearbeitet vor allem das Sichtbare: Rollen, Meetings, Prozesse, Zielsysteme. Das kann helfen, bleibt aber Oberfläche, solange die tieferen Regeln gleich bleiben:
Wer entscheidet de facto?
Was passiert bei Unsicherheit?
Wofür gibt es Anerkennung – und wofür Ärger?
Genau hier landen viele SAFe‑, LeSS‑ oder sonstige Skalierungsversuche in einem Paradox:
Formal wird skaliert, Boards und Events sind da – faktisch bleibt die Organisation in der alten Entscheidungs‑ und Eskalationslogik hängen.
Das Ergebnis kennst du:
Im besten Fall entstehen agile Inseln.
Im schlimmsten Fall agiles Theater – viel Ritual, wenig Entwicklung.
Die Frage ist also nicht, ob Frameworks „schlecht“ sind. Die Frage ist:
Auf welchem Betriebssystem laufen sie – und was verändert dieses Betriebssystem (noch) nicht?
Eine Ebene tiefer: Organisationen als komplexe soziale Systeme
Organisationen sind als komplexe soziale Systeme zu verstehen, was erst einmal Ernst zu nehmen ist und sich daraus ein entsprechender Fokus ergibt. Systeme verhalten sich nicht wie Maschinen, sondern organisieren sich über Sinn, Erwartungen und Entscheidungen.
Daraus folgen drei Beobachtungen, die den Kern des Agile Transformation Navigators bilden:
-
Ja, es gibt erkennbare Erfolgsrezepte – wiederkehrende Muster aus erfolgreichen Transformationen.
-
Das Wesen einer Transformation liegt nicht im „Projektcharakter“ und AUCH NICHT in Skalierungsframeworks. Es liegt in der Logik, wie das System Entscheidungen, Lernen und Macht organisiert.
-
Um diese Logik zu lesen, braucht es ein Transformations‑Betriebssystem – eine Metaarchitektur, die zeigt, wie Organisationen sich verändern, nicht nur was sie tun.
In meinem Navigationsmodell bilden im Kern diese 3 Ebenen das Betriebssystem:
das 2‑Cycles‑Modell, systemische Archetypen und kognitive Biases.
1. Resonanz zwischen Weltbild, Struktur und Handlungen
Das 2‑Cycles‑Modell (in der Tradition von agilissence) bricht mit der Idee, man könne Organisationen durch das Austauschen von Bausteinen „reparieren“. Es nimmt ernst, dass Organisationen ihre Realität über Beobachtung und Entscheidungen konstruieren – und knüpft damit lose an Luhmanns Verständnis von Organisation als System von Entscheidungen an.
Vereinfacht unterscheidet 2‑Cycles drei Ebenen:
Innerer Zyklus – Weltbild & Motivation
Mentale Modelle, Identität, professionelle Selbstbilder, Sicherheitsbedürfnisse.
Was gilt als „gute Entscheidung“? Was fühlt sich riskant an? Was verspricht Anerkennung?Äußerer Zyklus – Struktur & Umfeld
Aufbauorganisation, Prozesse, Rollen, Governance, Metriken, Tools, Marktumfeld.
Kurz: die offiziellen Spielregeln und Rahmenbedingungen.Handlungen – die Mitte zwischen beiden
Konkretes Verhalten entsteht aus der Wechselwirkung von innerem und äußerem Zyklus:
Weltbild trifft Struktur – und daraus werden Entscheidungen, Routinen und Muster.
Das Systemische daran ist die Zirkularität:
Strukturen ermöglichen bestimmte Handlungen – und begrenzen andere.
Handlungen bestätigen oder irritieren Weltbilder.
Weltbilder beeinflussen, wie Strukturen interpretiert und genutzt werden.
Genau hier scheitern viele Transformationen:
Wer nur am äußeren Zyklus dreht (z.B. neue agile Rollen, neue Gremien), ohne den inneren Zyklus mitzunehmen, erzeugt Dissonanz – das berühmte „Agilitätstheater“.
Wer nur mit Haltung, Mindset und Kultur arbeitet, ohne den äußeren Zyklus zu verändern, produziert Einsichten ohne Konsequenz: „Wir würden ja gern, aber…“.
2‑Cycles ist in diesem Sinne kein weiteres Framework, sondern eine Reflexionsbrille:
Es zwingt uns, bei jeder Maßnahme zu fragen:
Was passiert im inneren Zyklus – Weltbild, Sicherheit, Identität?
Was passiert im äußeren Zyklus – Struktur, Mandate, Governance?
Und welche Handlungen werden dadurch wahrscheinlicher oder unwahrscheinlicher?
Human Robot Agent
2. Systemische Archetypen: Muster statt Schuld
Die zweite Ebene des Navigators kommt aus der Komplexitäts‑ und Systemdynamik: systemische Archetypen.
Archetypen sind wiederkehrende Strukturmuster in Organisationen, etwa:
Problemverschiebung: Symptome werden bearbeitet (z.B. mehr Trainings, mehr Reporting), während die strukturelle Ursache unberührt bleibt.
Fixes that fail: Kurzfristige Lösungen entlasten, führen langfristig aber zu stärkeren Nebenwirkungen (z.B. zusätzliche Freigabeebenen, die alles verlangsamen).
Shifting the burden: Man externalisiert Verantwortung auf Spezialrollen oder Berater:innen, statt die eigene Lernfähigkeit zu entwickeln.
Der Wert dieser Archetypen liegt nicht in ihrer Originalität, sondern in ihrer Wirkung auf die Beobachtung:
Sie entmystifizieren Widerstand: Das System verhält sich nicht irrational, sondern stabilisiert sich – oft entgegen der erklärten Absicht.
Sie verschieben den Fokus von Personen auf Architektur: Statt „wer blockiert?“ wird gefragt „welche Schleife, welches Anreizsystem, welche Schnittstelle erzeugt dieses Verhalten?“.
Sie markieren Hebelpunkte: Kleine strukturelle Veränderungen an den richtigen Stellen können kaskadierende Effekte auf das Gesamtverhalten haben.
Für Transformation bedeutet das:
Bevor du das nächste Skalierungsframework einführst, lohnt es sich, deine Organisation archetypisch zu „lesen“: In welchem Muster stecken wir? Was stabilisiert es? Und wo wären Hebelpunkte, die mehr bewirken als die zehnte Initiative?
3. Kognitive Biases: Das organisationale Immunsystem
Die dritte Ebene ergänzt diese Architektur um den psychologischen Unterbau die wir aus dem Buch von Daniel Kahnemann kennen, „Schnelles vs. langsamens Denken“ wo er sich den Erkenntnissen von Beck bedient – es geht um die „kognitiven Biases“ . Sie beschreiben robuste Muster, wie Menschen in unsicheren, komplexen Situationen wahrnehmen und entscheiden – und sind damit ein entscheidender Teil des organisationalen Immunsystems.
Typische Bias die ich in Transformationen immer wieder angetroffen habe:
Status‑quo‑Bias: Das Bekannte wirkt sicherer als das Neue – selbst wenn die Fakten dagegensprechen.
Sunk‑Cost‑Fallacy: Je mehr in eine Initiative investiert wurde, desto schwerer fällt der Ausstieg.
Loss Aversion: Potenzieller Verlust von Status, Einfluss oder Sicherheit wiegt schwerer als mögliche Gewinne.
Groupthink: Harmonie‑Wunsch unterdrückt abweichende Meinungen, Risiken bleiben unausgesprochen.
Für den Transformationsnavigator sind Biases keine Psychotricks, sondern Musterspiegel:
Sie erklären, warum manche Maßnahmen fast zwangsläufig Widerstand erzeugen – etwa wenn Mandate, Budgets oder Status verschoben werden.
Sie machen sichtbar, an welchen Stellen in einer Roadmap Reibung zu erwarten ist – nicht als Ausnahme, sondern als Normalfall.
Sie ermöglichen eine andere Gesprächsqualität: weg von „die wollen nicht“ hin zu „welcher Schutzmechanismus ist hier aktiv – und was braucht es, damit ein nächster Schritt überhaupt psychologisch zumutbar ist?“.
Biases erinnern uns ständig daran, dass Transformation nicht im neutralen Raum passiert.
Sie hilft, Widerstände nicht zu moralisieren, sondern als Teil eines funktionierenden Betriebssystems mitzudenken und zu verorten – in Kommunikation, Taktung, Experimentdesign und Entscheidungsfindung.
Reflexion: Was das über Transformation verrät
Wenn man diese drei Ebenen zusammennimmt – 2‑Cycles, Archetypen, Biases – entsteht ein anderes Bild von Transformation:
Ja, es gibt Erfolgsmuster aus anderen Unternehmen. Aber sie lassen sich nicht als Blaupause kopieren, ohne das zugrundeliegende Betriebssystem zu verstehen. Hier will ich einige beispielhaft nennen, die in verschiedenen Kontexten, ob Mittelständler, StartUp oder Konzern übereinstimmend genannt werden:
Ein klares, geteiltes Zielbild, das über Effizienz hinaus Orientierung gibt und die „Warum-Frage“ beantwortet.
Kohärente Führung, die nicht nur neue Strukturen anordnet, sondern Entscheidungslogik, Umgang mit Fehlern und Priorisierung sichtbar vorlebt.
Crossfunktionale Wertstrom-Teams, die wirklich end‑to‑end Verantwortung tragen – inklusive Mandat für Priorisierung und Entscheidung.
Eingebaute Lernzyklen (Experimente, Reviews, Retrospektiven), die Teil der Steuerung sind, nicht „nice to have daneben“.
Ein angepasstes Operating Model (Governance, KPIs, Anreize), das Kundennutzen und Time‑to‑Market belohnt statt nur Auslastung und Bereichsoptimierung
Der entscheidende Unterschied zwischen „wir machen Transformation“ und „wir haben Transformationsfähigkeit“ liegt darin, ob eine Organisation ihr eigenes Betriebssystem beobachten und justieren kann.
Skalierungsframeworks können auf diesem Betriebssystem laufen – sie ersetzen es aber nicht. Ohne diese Metaebene bleiben sie mechanistische Lösungen für ein nicht‑mechanistisches Problem.
Der Agile Transformation Navigator, den ich in meinem Buch weiter ausarbeite, ist deshalb kein weiteres „Vorgehensmodell“, das dir sagt, was du in welchem Quartal tun sollst.
Er ist eher eine Landkarte, ein Denkrahmen, mit der du:
die Resonanz zwischen innerem und äußerem Zyklus deiner Organisation lesen,
wiederkehrende Muster (Archetypen) erkennen
und typische Bias‑Schleifen einpreisen kannst – bevor du die nächste große Initiative startest.
Der Denkrahmen und auch die Pfade die man einschlagen kann, zeige ich und gebe klare Handlungsempfehlungen. Am Ende bleibt aber die Erkenntnis:
Transformation wird nicht dadurch wirksamer, dass wir größere Projekte aufsetzen – sondern dadurch, dass wir das Betriebssystem verstehen, auf dem sie läuft.
Weiterführende Schlagwörter
Transformation als Betriebssystem. Always-on Transformation. Transformationsfähigkeit (Transformability). Organisationsentwicklung (OE). Operating Model. Governance & Entscheidungslogik. Organisationsdesign. Wertstrom / Value Stream. Portfolio- & Ressourcensteuerung. Agile Transformation. Agile Operating Models. Skalierungsframeworks (SAFe, LeSS). Agile Inseln. Agiles Theater. Autonomie & Leitplanken. Psychologische Sicherheit. Lernzyklen / Continuous Learning. 2-Cycles (agilissence). Systemische Meta-Ebene. Systemische Archetypen. Fixes that fail. Shifting the burden / Problemverschiebung. Rückkopplungsschleifen. Komplexitätstheorie. Komplexe vs. komplizierte Probleme. Engpässe / Constraints. Schnittstellen & Abhängigkeiten. Time-to-Market. Nutzerzentrierung / Customer Centricity. Outcome statt Output. End-to-end-Wertschöpfung. Entscheidungsstaus. Priorisierung. Status-quo-Bias. Sunk-Cost-Fallacy. Confirmation Bias. Groupthink. Loss Aversion. Debiasing. Pre-Mortem. OKRs als Lerninstrument. Retrospektiven & Reviews. Experiment-Portfolios. Automatisierung (n8n). Enablement & Coaching. Führung in Transformation.