IT-Organisation und VorgehenLesezeit 3 Minuten

Agil oder klassisch? Die Frage ist falsch gestellt

Die Grundsatzdiskussion über Vorgehensmodelle wird in vielen Häusern seit Jahren geführt und ist nicht zu gewinnen. Sie ist auch nicht nötig: Zwei Eigenschaften des Vorhabens entscheiden die Frage, und beide lassen sich prüfen.

In fast jedem Haus mit einer gewachsenen IT gibt es eine Fraktion, die agiles Vorgehen für die Antwort hält, und eine, die es für die Ursache der aktuellen Lage hält. Beide haben Belege, beide haben Projekte, auf die sie zeigen können. Die Diskussion ist deshalb nicht entscheidbar – sie ist nur falsch angesetzt.

Ich bin in dieser Debatte kein guter Verbündeter für eine der beiden Seiten. Ausgebildet bin ich klassisch – Zertifikatsstudium Projektmanagement, Zertifizierung als PRINCE2 Practitioner – und später habe ich in zwei Häusern agile Arbeitsweisen eingeführt. Beides hat funktioniert, und beides hat an Stellen nicht funktioniert.

Die Wahl des Vorgehens ist keine Haltungsfrage. Sie hängt an zwei Eigenschaften des konkreten Vorhabens.

Erste Eigenschaft: Wie klar ist das Ziel?

Es gibt Vorhaben, bei denen am Anfang präzise feststeht, was am Ende dastehen muss. Eine aufsichtsrechtliche Meldepflicht, eine Schnittstelle nach einer veröffentlichten Spezifikation, die Migration eines bekannten Datenbestands. Der Weg ist aufwendig, das Ziel ist unstrittig.

Und es gibt Vorhaben, bei denen das Ziel erst durch die Arbeit entsteht. Eine neue Kundenoberfläche, ein Produkt für einen Markt, den man noch nicht kennt, der Einsatz eines Verfahrens, dessen Trefferquote man vorher nicht kennt. Hier ist jede detaillierte Vorausplanung eine Vermutung, die als Plan verkleidet ist.

Im ersten Fall ist ein klassischer Zuschnitt die ehrlichere Wahl. Im zweiten Fall produziert er Dokumente, die nach drei Monaten Makulatur sind.

Zweite Eigenschaft: Wie teuer ist eine Korrektur?

Iteratives Arbeiten setzt voraus, dass man das Ergebnis eines Zyklus verwerfen oder umbauen kann, ohne dass es ruinös wird. Bei einer Weboberfläche trifft das zu. Bei der Datenhaltung eines Kernsystems, einem Vertrag mit einem Rechenzentrumsbetreiber oder einer Schnittstelle, die dreißig Nachbarsysteme nutzen, trifft es nicht zu.

Je teurer die Korrektur, desto mehr lohnt Vorausdenken – nicht, weil Planung ein Wert an sich wäre, sondern weil der Versuch billiger ist als der Rückbau.

Die vier Fälle

• Ziel klar, Korrektur teuer. Klassisch, und zwar ohne schlechtes Gewissen. Kernsystemablösung, Migration, regulatorische Umsetzung.
• Ziel unklar, Korrektur günstig. Iterativ. Produktentwicklung, Oberflächen, Pilotvorhaben mit lernenden Verfahren.
• Ziel unklar, Korrektur teuer. Der unangenehmste Fall. Hier gehört an den Anfang keine Umsetzung, sondern eine Klärung: ein Prototyp, eine Vorstudie, eine Entscheidungsvorlage. Wer hier direkt in die Umsetzung geht, wählt zwischen zwei schlechten Optionen.
• Ziel klar, Korrektur günstig. Beides funktioniert. Nehmen Sie, was zur Umgebung passt, und reden Sie nicht darüber.

Der Fall, der beides braucht

Große Vorhaben sind selten einheitlich. Eine Kernsystemablösung enthält in der Regel beides: einen Teil mit festem Ziel und teurer Korrektur, und einen Teil – meist die Oberflächen und die Auswertungen – mit unklarem Ziel und günstiger Korrektur.

Diese Teile unterschiedlich zu behandeln ist möglich, aber nicht gratis. Es verlangt eine Schnittstelle zwischen ihnen, die verabredet ist, und einen Lenkungsausschuss, der aushält, dass zwei Teile desselben Programms unterschiedlich berichten. Wer das nicht will, muss sich für einen Modus entscheiden – und dann für den, der zum teuren Teil passt. Der günstige Teil verträgt ein zu schweres Vorgehen; der teure verträgt kein zu leichtes.

Was sich daraus für die Debatte ergibt

Wenn in Ihrem Haus die Methodenfrage zur Grundsatzfrage geworden ist, liegt das meist daran, dass sie einmal pauschal entschieden wurde – in eine Richtung, die zur Hälfte der Vorhaben nicht passte. Die Lösung ist nicht, die Pauschalentscheidung umzudrehen. Sie ist, die Entscheidung dort zu treffen, wo sie hingehört: bei jedem Vorhaben, mit einer Begründung aus diesen zwei Eigenschaften, in zwei Sätzen in der Projektvorlage.

← Alle Beiträge