Das Problem, das SAFe nicht löst, weil es das falsche Problem löst
SAFe wird oft in einem Atemzug mit Scrum genannt. Sein struktureller Fehler ist aber ein anderer — und er zeigt sehr genau, wohin es nicht führt, ein Koordinationsproblem mit noch mehr Koordination zu beantworten.
Im letzten Artikel dieser Serie ging es darum, dass Scrum zwei unterschiedliche Probleme gleichzeitig gelöst hat: Koordination zwischen Menschen und Unsicherheit über echte Anforderungen. SAFe wird häufig als "Scrum, nur größer" verstanden — als würde man dasselbe Rezept einfach auf mehr Teams anwenden. Das trifft den eigentlichen Unterschied nicht.
Ein Koordinationsproblem, beantwortet mit mehr Koordination
SAFe versucht, die Koordinationskosten auf Organisationsebene zu skalieren, indem es zusätzliche Prozessebenen einführt: Program Increments, Release Trains, zusätzliche Rollen, die zwischen einzelnen Teams vermitteln sollen. Auf den ersten Blick wirkt das folgerichtig — wenn ein Team Koordination braucht, brauchen zehn Teams eben mehr davon.
Das Problem liegt in dem, was dabei nicht passiert: Die Konsistenzprüfung über den gesamten Anforderungskorpus hinweg wird durch diese zusätzlichen Ebenen nicht gelöst. Sie bekommt lediglich eine weitere Ebene hinzugefügt, die selbst wieder koordiniert werden muss. Ein Datenmodell, das über zehn Teams hinweg konsistent bleiben soll, wird durch ein zusätzliches PI-Planning nicht automatisch konsistenter — es wird nur eine zusätzliche Besprechung eingeführt, in der jemand versuchen soll, die Inkonsistenzen von Hand zu erkennen, bevor sie zu Problemen werden.
SAFe beantwortet damit ein Koordinationsproblem mit mehr Koordination, statt die Notwendigkeit für Koordination strukturell zu reduzieren. Es ist in diesem Sinn fast das Gegenbeispiel zu dem, was gerade durch KI-gestützte Entwicklung möglich wird.
Warum das gerade jetzt sichtbar wird
Solange Koordination zwischen Menschen unvermeidbar war, war SAFes Antwort nicht unvernünftig — mehr Prozess für mehr Komplexität ist eine naheliegende Reaktion, wenn keine bessere Alternative zur Verfügung steht. Das Problem war nie, dass SAFe schlecht gemeint war. Das Problem war, dass es die einzige verfügbare Antwort auf ein Skalierungsproblem war, für das es bislang keine strukturelle Lösung gab.
Wenn ein wachsender Teil der Umsetzungskoordination an KI-Agenten übergeht, verändert sich diese Ausgangslage grundlegend. Nicht, weil KI-Agenten "besser koordinieren" als Menschen, sondern weil die Größe, die koordiniert werden muss, überhaupt kleiner wird. Ein Konflikt zwischen zwei KI-generierten Vorschlägen lässt sich maschinell gegen einen gemeinsamen, konsistent gehaltenen Anforderungskorpus prüfen — ohne PI-Planning, ohne zusätzliche Rolle, ohne eine weitere Besprechung, in der Menschen versuchen, etwas im Kopf zu behalten, das eigentlich zu groß für einen einzelnen Kopf ist.
Die eigentliche Lehre aus SAFe
SAFe ist ein gutes Lehrstück dafür, was passiert, wenn man ein Problem an der falschen Stelle skaliert. Mehr Prozess-Overhead löst kein Konsistenzproblem, es verteilt nur die Verantwortung dafür auf mehr Menschen, die sich wiederum untereinander abstimmen müssen. Die eigentliche Lösung liegt nicht in mehr Koordination, sondern in einem Mechanismus, der Konsistenz direkt prüfbar macht — unabhängig davon, wie viele Teams oder wie viele Features gleichzeitig daran arbeiten.
Im nächsten Artikel geht es genau um diesen Mechanismus: drei unabhängige Achsen, an denen sich jede Entwicklungsmethode messen lässt — und warum sich gerade eine davon durch KI zum ersten Mal technisch lösen lässt, während eine andere unverändert bleibt, ganz gleich wie viel Prozess man draufpackt.