IT-Organisation und VorgehenLesezeit 3 Minuten

Wann Agilität der falsche Weg ist

Über die Voraussetzungen agilen Arbeitens wird viel gesprochen. Über die Fälle, in denen es trotz aller Voraussetzungen die falsche Wahl ist, deutlich weniger.

Ich arbeite in Programmen, die iterativ aufgesetzt sind, und halte das in vielen Fällen für die bessere Wahl. In manchen Fällen rate ich davon ab, und das hat nichts mit fehlender Reife der Organisation zu tun. Es gibt Vorhaben, bei denen iteratives Vorgehen strukturell nicht passt.

Fünf Fälle

1. Das Ergebnis ist vorgegeben und nicht verhandelbar

Eine Meldepflicht an eine Aufsichtsbehörde, eine gesetzlich gesetzte Frist, eine Spezifikation eines Marktteilnehmers, an die sich alle halten müssen. Hier gibt es keinen Erkenntnisgewinn durch Iteration, weil es nichts zu entscheiden gibt. Es gibt eine Menge Arbeit und ein Datum. Das ist ein Planungsproblem, kein Lernproblem.

Ich habe mehrere solcher Vorhaben geleitet – ein Berechtigungsmanagement nach aufsichtsrechtlichen Vorgaben, die Überarbeitung des internen Kontrollsystems für die risikobasierten IT-Kontrollen eines Versicherers. Dort gibt es kein sinnvolles Minimalprodukt. Die Anforderung ist erfüllt oder sie ist es nicht, und die Prüfung findet an einem festen Termin statt.

2. Teilergebnisse haben keinen Wert

Der Nutzen iterativer Lieferung entsteht daraus, dass ein Teil des Ergebnisses früher wirkt. Bei einer Migration ist das nicht der Fall. Als ich eine Rechenzentrumsmigration geleitet habe, bei der sämtliche Anwendungen und Datenbanken eines Hauses umzogen, war ein zu sechzig Prozent migrierter Bestand kein Zwischenergebnis, sondern ein Zustand, den niemand haben wollte. Wo der Wert erst mit der Vollständigkeit entsteht, ist die iterative Lieferung eine Technik ohne Zweck – sinnvoll bleibt sie dann nur intern, als Mittel zur Risikosteuerung, nicht als Lieferweg.

3. Die Korrektur kostet mehr als die Planung

Datenmodelle in Kernsystemen, Schnittstellenverträge mit vielen Nutzern, Infrastrukturentscheidungen, mehrjährige Verträge. Solche Festlegungen holt man nicht zurück. Der Satz „das stellen wir in der nächsten Iteration richtig“ gilt hier nicht.

4. Es gibt keinen Entscheider mit Mandat

Das ist der Fall, der am häufigsten übersehen wird. Ohne eine Person, die fachliche Festlegungen innerhalb von Tagen treffen darf, verliert iteratives Vorgehen seinen einzigen echten Vorteil. Es bleiben die Nachteile: weniger Vorausplanung, weniger Dokumentation, kürzere Zyklen – und eine Wartezeit, die alles auffrisst. In so einer Umgebung liefert ein klassisch aufgesetztes Vorhaben zuverlässiger. Nicht weil es besser wäre, sondern weil es die fehlende Entscheidungsfähigkeit verträgt.

5. Das Vorhaben ist eine Beschaffung

Wenn im Kern eine Standardsoftware eingeführt wird, ist der Spielraum begrenzt. Was das Produkt kann, steht fest; was es nicht kann, wird nicht durch Iteration entdeckt, sondern durch Lesen. Hier lohnt die Energie vorn, in der Auswahl und in der Entscheidung über Anpassungen – nicht in einem Vorgehensmodell für die Einführung.

Was man stattdessen tut

Von diesen Fällen abzuraten heißt nicht, zu einem Vorgehen von 1995 zurückzukehren. Was aus der agilen Praxis in jedem Fall trägt:

• Kurze Rückkopplung mit der Fachseite, auch wenn nicht iterativ geliefert wird. Zeigen, was entsteht, in Wochen statt in Monaten.
• Das Risiko zuerst. Den schwierigsten Teil nach vorn ziehen, nicht den angenehmsten. Das ist der wertvollste Beitrag agiler Praxis und von jedem Vorgehensmodell unabhängig.
• Lieferfähigkeit nachweisen, nicht behaupten. Früh einmal durch die gesamte Kette gehen, auch mit wenig Inhalt.

Die Entscheidung gegen iteratives Vorgehen ist also keine gegen diese Praktiken. Sie ist eine Entscheidung darüber, wie geliefert und wie gesteuert wird – und sie gehört begründet in die Projektvorlage, nicht in eine Grundsatzdebatte.

← Alle Beiträge