Ich bin als Coach in vielen Organisationen unterwegs, und wenn man das lange genug macht, fängt man an, Muster zu sehen, ob man will oder nicht. Manche davon sind langweilig, weil sie in jedem Buch stehen. Dieses hier steht in keinem, und deshalb schreibe ich es auf.
Wenn in einer grösseren Organisation etwas hakt, gibt es einen Reflex: Es liegt an der Führung. Genauer, an der mittleren Führung, der berühmten Lehmschicht, die alles aufsaugt und nichts durchlässt. Ich habe diese Diagnose selbst oft genug gestellt. Aber in den letzten Jahren sehe ich etwas anderes, und zwar in Firmen, die sonst wenig gemeinsam haben: Versicherer, Bahnen, Verwaltungen, Maschinenbauer. Der Ärger sitzt nicht in der Führung. Er sitzt in der Koordination.
Konkret: in der Ebene, auf der zehn, zwölf, manchmal fünfzehn Teams gemeinsam etwas liefern sollen. In SAFe heisst diese Ebene Agile Release Train, und weil SAFe im deutschsprachigen Raum das mit Abstand verbreitetste Skalierungsmodell ist, sehe ich sie meistens in dieser Form. Aber ich will gleich zu Beginn sagen: Das ist kein SAFe-Text. Organisationen mit LeSS, mit selbstgebauter Skalierung oder mit gar keinem Modell haben dasselbe Problem, sie haben nur keinen Namen dafür. SAFe hat immerhin einen Namen. Das ist schon mal etwas.
Was ich sehe
Die Szenen ähneln sich so sehr, dass ich inzwischen nach der ersten Stunde in einer neuen Organisation ungefähr weiss, was kommt.
Da ist das Program Board. Zwei Tage lang wurde es im PI Planning mit roten Fäden bespannt, jede Abhängigkeit sauber eingetragen, und alle waren ein bisschen stolz. Drei Wochen später hängt es noch da, aber niemand hat es mehr angefasst. Die Fäden sind noch dieselben, die Realität nicht mehr.
Da ist die Kennzahl, die niemand deuten kann. Der Train meldet eine Predictability von 74 Prozent. Der Business Owner fragt, ob das gut ist. Der RTE sagt, es sei besser als letztes Mal. Ob 74 Prozent Zusagen-Erfüllung ein Erfolg oder ein Alarmsignal ist, kann in dem Raum niemand sagen, und das Erstaunliche ist: Es stört auch niemanden.
Da ist die Durchlaufzeit, die keiner kennt. Ich frage, wie lange es dauert, bis aus einer Feature-Idee ein Release wird. Erst Schweigen, dann Schätzungen, die zwischen „ein PI“ und „kommt drauf an“ liegen. Wenn wir dann gemeinsam nachrechnen, landen wir bei zwei, drei, manchmal vier Planungszyklen. Für ein Feature. Das ist keine Durchlaufzeit, das ist eine Verharzung.
Da ist das Inspect & Adapt, bei dem zum dritten Mal dieselbe Ursache auf dem Flipchart steht. Zu viele Abhängigkeiten zu Team X. Jedes Mal wird eine Massnahme beschlossen, jedes Mal ist beim nächsten Mal dieselbe Ursache wieder da. Nicht, weil die Leute faul wären, sondern weil niemand das Mandat hat, an der Struktur etwas zu ändern.
Und da ist der RTE. Meist eine der fähigsten Personen im Raum, verantwortlich für den Fluss von zwölf Teams, und wenn ich frage, ob er Arbeit ablehnen oder stoppen darf, kommt ein Lächeln, das ich inzwischen gut kenne. Servant Leader, sagt das Framework. Was in der Praxis heisst: Verantwortung ja, Entscheidungsbefugnis nein.
Dazu kommen die kleineren Dinge. Zweihundert offene Features in einem Train mit Kapazität für vierzig. Abhängigkeiten, die drei Planungszyklen lang mitgeschleppt werden, weil sie in jedem Zyklus knapp nicht Priorität haben. Prioritäten, die vom Portfolio kommen wie eine Wunschliste, ohne dass je Kapazität zurückgemeldet wird. Sync-Meetings, in denen Status ausgetauscht, aber nichts entschieden wird.
Nichts davon ist ein Führungsproblem im klassischen Sinn. Die Leute wollen. Sie haben nur kein Instrument.
Ist das Zufall?
Ich war lange unsicher, ob ich da ein echtes Muster sehe oder nur meine eigene Brille. Also habe ich nachgelesen. Es gibt inzwischen erstaunlich viel Forschung zu skalierter Produktentwicklung, und sie ist deutlicher, als ich erwartet hatte.
Eine Gruppe um Maria Paasivaara hat eine grosse Finanzorganisation mit vier Release Trains über Jahre begleitet. Ihr zentraler Befund: Die schwierigste Aufgabe war, die Trains an den tatsächlichen Wertströmen auszurichten. Wo das nicht gelang, entstanden Abhängigkeiten zwischen den Trains und ein Koordinationsaufwand, der die Beweglichkeit auffrass. Das Value-Stream-Mapping, das geholfen hätte, wurde nicht gemacht. Grund: interne Machtpolitik.
Zwei Forscher vom Fraunhofer IESE haben das Framework selbst analysiert und einen Satz geschrieben, den ich seither oft zitiere: SAFe schreibt vor, wann synchronisiert wird, sagt aber nichts darüber, wie die Arbeit, die an den Schnittstellen geteilt wird, gemanagt werden soll. Anders gesagt: Es gibt eine Kadenz, aber keinen Fluss.
Und dann gibt es Stimmen aus dem Framework selbst, die ich fairerweise ernster nehme als die üblichen Kritiker. Ein SAFe Fellow schreibt über das Program Board: Zu viele rote Fäden heissen zu viele Abhängigkeiten, und zu viele Abhängigkeiten heissen, dass das Netzwerk falsch konfiguriert ist. Ein Autor auf der offiziellen Scaled-Agile-Seite sagt, nach seiner Erfahrung seien die Iterationspläne aus dem PI Planning etwa zu 60 Prozent genau. Das ist keine Messung, das ist eine Erfahrungsaussage, aber sie kommt aus dem Haus, das das Ritual verkauft.
Damit das nicht zu einseitig wird: Eine Studie mit über viertausend Teams hat 2024 gezeigt, dass es für die Effektivität der Teams praktisch keine Rolle spielt, welches Skalierungsmodell die Organisation nutzt. Die Teams sind unter SAFe nicht schlechter als unter irgendetwas anderem. Ich glaube das sofort. Es bestätigt nur, was ich sehe: Das Problem liegt nicht in den Teams. Es liegt dazwischen.
Die Frage, die mich nicht loslässt
Hier wird es für mich interessant. SAFe gibt es seit über zehn Jahren. Im deutschsprachigen Raum betreiben Dutzende grosser Organisationen Release Trains, manche zwei, manche über hundert. Es gibt Zertifizierungen, Konferenzen, Berichte, Erfolgsgeschichten.
Und es gibt keine einzige öffentliche Zahl darüber, wie diese Koordinationsebene tatsächlich performt.
Keine Verteilung der Zusagen-Erfüllung über echte Trains. Keine Durchlaufzeiten von Feature-Idee bis Release. Keine Zahl dazu, wie viele Abhängigkeiten pro Zyklus entstehen und wie viele davon aufgelöst werden. Nichts über die Belastung der Rolle, die das alles tragen soll. Der Hersteller publiziert einen Zielkorridor (80 bis 100 Prozent Predictability gelten als „verlässlich“), aber keine Ist-Werte. Die Forschung hat Fallstudien, aber keine Messreihen. Und die Firmen selbst messen es entweder nicht oder behalten es für sich.
Ich finde das bemerkenswert. Wir haben eine Ebene, auf der die meiste Koordination stattfindet, auf der die meiste Zeit verloren geht, und über die niemand Zahlen hat. Wenn das in einem Produktionsbetrieb so wäre, würde man von einem blinden Fleck sprechen. Ich nenne es deshalb auch so.
Was man tun könnte
Ich habe keine fertige Antwort, aber ich habe eine Vermutung, und die kommt aus einer Ecke, die mit SAFe nichts zu tun hat.
Klaus Leopold hat vor Jahren beschrieben, dass Organisationen auf drei Höhen fliegen: die Teams unten, die Strategie oben, und dazwischen die Ebene, auf der Ende-zu-Ende koordiniert wird. Er nennt sie Flight Level 2. Sein Punkt war damals schon: Die meisten Organisationen optimieren Teams und wundern sich, dass die Organisation nicht schneller wird. Eine Organisation ist mehr als die Summe ihrer Teams. Ich will nicht, dass gearbeitet wird, sagt er, ich will, dass geliefert wird.
Das ist genau die Ebene, um die es hier geht. Und für diese Ebene gibt es Werkzeuge, die seit zwanzig Jahren funktionieren, nur werden sie fast nie dort eingesetzt: ein Board, das nicht die Teams zeigt, sondern den Fluss der Features durch den ganzen Train. WIP-Limits auf dieser Ebene, also die Entscheidung, dass nicht zweihundert Features gleichzeitig offen sein dürfen. Explizite Regeln, was mit einer Abhängigkeit passiert, wenn sie entsteht, statt sie nur auf ein Board zu pinnen. Und die schlichte, fast peinliche Übung, die Durchlaufzeit zu messen.
Und dann gibt es eine Idee aus dem Lean-Werkzeugkasten, die älter ist als jedes Skalierungsframework und die ich auf dieser Ebene fast nie sehe: der Obeya. Ein Raum, physisch oder digital, in dem alles hängt, was für die Steuerung des Trains wichtig ist. Der Fluss, die Engpässe, die Abhängigkeiten, die Entscheidungen, die anstehen. Nicht als Reporting für oben, sondern als Arbeitsraum für die, die koordinieren. Wer einmal erlebt hat, wie sich ein Sync-Meeting verändert, wenn es vor einer Wand stattfindet, auf der der echte Zustand des Trains sichtbar ist, statt vor einer Jira-Filterliste, versteht, warum Toyota das seit Jahrzehnten macht.
Wenn ich im Bild bleibe, das mir bei diesen Organisationen immer kommt, einem Schiff mit zwölf Ruderbänken, auf denen alle kräftig rudern: Diesen Schiffen fehlen weder Ruderer noch ein Kapitän. Ihnen fehlt die Brücke. Der Ort, von dem aus man sieht, wohin das Schiff fährt und was ihm im Weg liegt. Das klingt banal. In jeder Organisation, in der ich es gesehen habe, war es das nicht.
Wo ich ehrlich sein muss
Ich schreibe das nicht ganz uneigennützig. Wir bei Wertwandler machen genau so etwas beruflich, und wer mir jetzt unterstellt, ich hätte ein Problem beschrieben, für das ich zufällig die Lösung verkaufe, hat nicht ganz unrecht. Ich würde nur sagen: Die Frage, warum nach zehn Jahren niemand diese Ebene misst, ist trotzdem berechtigt. Und sie ist mir wichtiger als die Antwort, die ich darauf habe.
Deshalb ein Vorschlag statt eines Angebots. Ich sammle solche Beobachtungen. Wenn du in einem Train arbeitest, als RTE, als Business Owner, als Product Owner, als jemand, der das Schiff finanziert, und du erkennst etwas von dem wieder, was hier steht, dann schreib mir. Und wenn du in einem Train arbeitest, bei dem es anders ist, bei dem das Board lebt, die Durchlaufzeit bekannt ist und der RTE Nein sagen darf: dann schreib mir erst recht. Das wäre die interessantere Geschichte.
Irgendwann, wenn genug zusammengekommen ist, gibt es Zahlen. Dann wissen wir, ob ich ein Muster gesehen habe oder nur meine Brille.
—
Quellen
1. Putta, A., Paasivaara, M., Lassenius, C. (2023/2024). SAFe transformation in a large financial corporation. Empirical Software Engineering 29. https://link.springer.com/article/10.1007/s10664-023-10420-w
2. Theobald, S., Schmitt, A. (2020). Dependencies of Agile Teams: An Analysis of the Scaled Agile Framework. XP 2020 Workshops. https://link.springer.com/chapter/10.1007/978-3-030-58858-8_22
3. Yeret, Y. (2020). SAFe Program Dependency Board Retrospective. https://yuvalyeret.medium.com/safe-program-dependency-board-retrospective-1c3f0aa0b080
4. Stroman, D. (2022). PI Planning: Plan to Discover. scaledagile.com. https://scaledagile.com/blog/pi-planning-plan-to-discover/
5. Verwijs, C., Russo, D. (2024). Do Agile scaling approaches make a difference? Empirical Software Engineering 29. https://arxiv.org/abs/2310.06599
6. Scaled Agile: ART Predictability Measure (Glossar). https://framework.scaledagile.com/blog/glossary_term/program-predictability-measure/
7. Leopold, K. (2018). Agilität neu denken. Interview: https://agile-unternehmen.de/klaus-leopold-agilitaet-neu-denken/
