Die Debatte zwischen agilem und klassischem Vorgehen wird meist als Glaubensfrage geführt und ist eine Sachfrage mit einer nüchternen Antwort. Sie lautet: Wie viel lässt sich am Anfang tatsächlich wissen?
Wo Anforderungen und Lösungsweg vorab bekannt sind, ist eine durchgeplante Umsetzung effizienter. Wo beides sich während der Arbeit klärt, ist iteratives Vorgehen die günstigere Antwort — weil es billiger ist, früh zu lernen als spät umzubauen. Alles Weitere folgt aus dieser einen Unterscheidung.
Der brauchbare Prüfstein
Eine nützliche Frage vor Projektbeginn: Können wir heute aufschreiben, woran wir in sechs Monaten erkennen, dass das Ergebnis richtig ist? Lautet die Antwort ja, spricht viel für eine geplante Umsetzung mit definierten Freigaben. Lautet sie nein, wird jede Vorabplanung eine Annahme sein, die später korrigiert werden muss.
Der Fehler in beide Richtungen ist teuer. Ein durchgeplantes Vorhaben mit unklarem Ziel produziert ein Ergebnis, das den Plan erfüllt und den Bedarf verfehlt. Ein iteratives Vorhaben mit klarem, feststehendem Ziel erzeugt Koordinationsaufwand ohne Gegenwert.
Hybrid ist keine Ausrede
In der Praxis ist die Mehrheit der Vorhaben gemischt, und das ist kein Kompromiss aus Unentschlossenheit. Ein typisches Muster: Die Steuerung läuft klassisch mit Phasen und Freigaben, weil Budget und Berichtspflicht das verlangen; innerhalb der Realisierung wird iterativ gearbeitet, weil die Lösung sich dort entwickelt.
Damit das funktioniert, muss eine Stelle sauber gestaltet sein: der Übergang. Eine Freigabe, die einen Umfang bestätigt, den die Iteration anschliessend verändert, erzeugt Widerspruch. Die Lösung ist nicht, die Freigabe abzuschaffen, sondern zu klären, was sie bestätigt — den Rahmen und die Ziele, nicht die Detailausgestaltung.
Was der DACH-Kontext beiträgt
In der Schweiz kommt ein praktischer Faktor dazu: Bei öffentlichen und regulierten Vorhaben ist HERMES häufig vorgegeben. Das schliesst iteratives Arbeiten nicht aus, aber es legt die Steuerungsebene fest. Wer in diesem Umfeld arbeitet, wählt nicht zwischen den Ansätzen, sondern gestaltet ihr Zusammenspiel.
Ähnliches gilt bei Vorhaben mit Nachweispflichten. Wo dokumentiert werden muss, wer wann was entschieden hat, braucht es definierte Entscheidungspunkte — unabhängig davon, wie innerhalb der Umsetzung gearbeitet wird.
Was eine späte Änderung kostet
Der eigentliche wirtschaftliche Unterschied zwischen den Ansätzen liegt in der Kostenkurve einer Änderung. In einem durchgeplanten Vorhaben ist eine Änderung früh billig und spät teuer, weil bereits darauf aufgebaut wurde. In einem iterativen Vorhaben bleibt sie über die Laufzeit gleichmässiger teuer — dafür entfällt der Sprung am Ende.
Daraus folgt eine praktische Regel: Je wahrscheinlicher eine späte Änderung ist, desto teurer wird das durchgeplante Vorgehen. Wer die Wahrscheinlichkeit realistisch einschätzt, hat die Methodenfrage weitgehend beantwortet — und diese Einschätzung ist zuverlässiger als jede Grundsatzdiskussion.
Die häufigsten Fehlgriffe
Drei Muster wiederholen sich. Erstens: agil eingeführt, um schneller zu werden, ohne die Voraussetzung zu schaffen — ein Team ohne Entscheidungsbefugnis wird nicht schneller, es wartet nur in kürzeren Abständen. Zweitens: klassisch geplant, obwohl der Bedarf unklar ist, und die Unklarheit über Änderungsanträge nachgeholt, was teurer ist als von Anfang an iterativ zu arbeiten. Drittens: die Methode gewechselt, statt das eigentliche Problem zu adressieren — meist fehlende Verfügbarkeit der Entscheider.
Die Entscheidung, die tatsächlich zählt
Wichtiger als die Wahl des Vorgehens ist eine andere Festlegung: Wer entscheidet, wenn sich der Umfang ändert, und wie schnell? Ein iteratives Vorhaben mit einem Entscheider, der alle vier Wochen verfügbar ist, arbeitet faktisch in Vier-Wochen-Blöcken. Ein klassisches Vorhaben mit einem präsenten Auftraggeber kann auf Änderungen schneller reagieren als sein Ruf vermuten lässt.
Die Methode setzt den Rahmen. Ob ein Projekt reaktionsfähig ist, entscheidet die Verfügbarkeit derer, die entscheiden dürfen — und das ist keine Methodenfrage.