Drei Achsen, an denen jede Methodik gemessen werden muss
Wasserfall, Scrum, SAFe, Spiralmodell — alle vier lösen dieselben drei Probleme unterschiedlich gewichtet und unterschiedlich gut. Wer die drei Achsen trennt, versteht sofort, warum die Debatte zwischen den Methoden meistens die falsche Debatte ist.
Die letzten beiden Artikel dieser Serie haben an zwei konkreten Beispielen gezeigt, woran Scrum und SAFe jeweils hängen. Dieser Artikel macht das explizit, was in beiden schon mitgeschwungen ist: Jede Entwicklungsmethode lässt sich entlang dreier unabhängiger Achsen bewerten, die in der öffentlichen Debatte fast immer miteinander vermengt werden.
Abstimmungskosten
Der Aufwand, mehrere Beteiligte so aufeinander abzustimmen, dass ihre Einzelarbeiten am Ende zu einem konsistenten Ganzen zusammenpassen. Bei menschlichen Teams wächst dieser Aufwand überproportional mit der Teamgröße — die Zahl der Kommunikationswege steigt schneller als die Zahl der Beteiligten selbst. Genau dieses Problem hat Scrum mit Sprints und festen Rollen handhabbar gemacht, und genau dieses Problem hat SAFe versucht, mit noch mehr Prozessebenen zu skalieren.
Vorabwissen
Der Grad, in dem die tatsächlichen Anforderungen an ein System schon zu Beginn bekannt oder erkennbar sind. Diese Unsicherheit ist eine Eigenschaft der Domäne und der Stakeholder, nicht des Entwicklungsprozesses selbst. Sie lässt sich durch keine Methode wegplanen, sondern nur durch echten Kontakt mit der Realität schrittweise reduzieren — durch Nutzerverhalten, Produktionsdaten, Marktreaktion. Agile Methoden haben genau hier ihren eigentlichen, berechtigten Fortschritt gegenüber Wasserfall: kurze Zyklen machen es billig, ein falsches Verständnis früh zu entdecken, statt es über Monate unbemerkt mitzuschleppen.
Konsistenzkosten
Der Aufwand, eine wachsende Menge an Anforderungen, Entscheidungen und Artefakten widerspruchsfrei zu halten, während sie sich über Zeit verändert. Historisch war diese Achse eng an die erste gekoppelt, weil derselbe Mensch, der Abstimmung leisten musste, auch für Konsistenzprüfung zuständig war — mit denselben Kapazitätsgrenzen. Diese Kopplung war kein Naturgesetz. Sie war eine Folge der bisher verfügbaren Werkzeuge, sonst nichts.
Die vier Methoden im Vergleich
| | Abstimmungskosten | Vorabwissen | Konsistenzkosten | |---|---|---|---| | Wasserfall | Nicht adressiert | Vorab gesammelt, aber später kaum korrigierbar | Menschlicher Disziplin überlassen | | Scrum | Durch kurze Zyklen und feste Rollen handhabbar gemacht | Aktiv verbessert durch schnelles Feedback | Durch Zerlegung in Slices eher verschärft | | SAFe | Durch zusätzliche Prozessebenen skaliert, nicht reduziert | Wie Scrum, aber durch Overhead verlangsamt | Nicht gelöst, zusätzliche Ebene nötig | | Spiralmodell | Nicht adressiert | Konzeptuell gelöst, praktisch selten durchsetzbar | Als Ziel erkannt, mangels Werkzeug nicht erreichbar |
Das Spiralmodell verdient dabei einen eigenen Blick, weil es in der öffentlichen Debatte fast vergessen ist. Bereits 1986 enthielt es die Grundidee risikogetriebener, wiederkehrender Verfeinerung, bei der frühere Arbeit nicht verworfen, sondern in jedem Zyklus in ein wachsendes Gesamtmodell zurückgeführt wird. Es wurde nie zur dominanten Methode — nicht weil die Idee falsch war, sondern weil es keinen praktikablen Mechanismus gab, sie umzusetzen. Genau diese fehlende Werkzeugunterstützung ist der Punkt, an dem sich gerade etwas verschiebt.
Was KI tatsächlich verändert — und was nicht
Der Einsatz von KI-Agenten als Ausführende verändert diese drei Achsen nicht gleichmäßig. Die Abstimmungskosten sinken bei KI-koordinierter Umsetzung gegen null — die gesamte Ceremony-Schicht, die dieses Problem bei Menschen lösen sollte, wird für die reine Umsetzungskoordination gegenstandslos. Die Konsistenzkosten werden durch zwei konkrete technische Mechanismen zum ersten Mal handhabbar: eine Prüfinstanz, die durch einen strukturell frischen Kontext keinen Anchoring Bias entwickeln kann, und eine maschinell geführte Herkunftsstruktur, die für jede Aussage im Anforderungskorpus festhält, wie verbindlich sie ist und wie sie entstanden ist.
Das Vorabwissen dagegen bleibt unverändert real. Kein noch so schneller und konsistenter Synthese-Mechanismus ersetzt den Kontakt mit der Realität, wenn die Unsicherheit nicht in der internen Widerspruchsfreiheit der Anforderungen liegt, sondern darin, dass Stakeholder oder Endnutzer selbst noch nicht wissen, was sie brauchen, bis sie etwas Konkretes vor sich haben. Das ist der Punkt, den jede Methodik, die "wir haben Scrum überholt" verspricht, ehrlich benennen muss, statt ihn zu verschweigen.
Im nächsten Artikel wird es persönlich: acht Monate, an einem eigenen Projekt, die eigene Methodik gegen sich selbst gebaut — und was dabei an Fehlern passiert ist, die keine Theorie vorhergesagt hätte.