CASE STUDY: Ziele im agilen Kontext

Diese Case-Study beschreibt die Veränderung des klassischen Release Management Prozesses in einer mitteleuropäischen Großbank hin zu einer agilen Vorgehensweise mit iterativer Entwicklung und zyklischer Lieferung neuer Software.

Ausgangssituation

In der Vergangenheit war der Release Management Prozess der Bank durch mittelfristige Planung mittels klassischem Projektmanagement geprägt.

Der gesamte konkrete Inhalt neuer Entwicklungsvorhaben wurde auf einmal im Vorhinein auf einzelne Requirements heruntergebrochen und in Form von klassischen Projekten bereits zu Beginn bis ins Detail nach Umfang und Aufwand ausdefiniert.

Die Ausformulierung der Anforderungen und deren Abstimmung mit den beteiligten Teams führte damit oft bereits zu Projektbeginn zu zeitlichen Schwierigkeiten und letztlich oft zu Verzögerungen.

Ganz im Sinne des Wasserfallmodells wurden dann auf Basis der detaillierten Anforderungen die Arbeitspakete beschrieben, Termine abgeleitet, konkrete Ressourcen verplant und plangemäß zur Umsetzung gebracht. Die Liste der Anforderungen, der Endtermin und die Kosten standen also zu Beginn fest. Der Fachbereich musste dann mehrere Monate auf die fertige Release warten.

Mängel oder am Kundennutzen vorbei entwickelte Features wurden damit sehr spät, oft erst nach Auslieferung der Software, identifiziert. Änderungen waren demnach nur noch in nachfolgenden Releases möglich.

Risiken durch die Langfristigkeit

Das Risiko im Projekt und für das Business war gleichermaßen hoch. Die Projektmanager waren sich zu keinem Zeitpunkt sicher, die Software in der geforderten Zeit, Qualität und geplanten Kosten tatsächlich ausliefern zu können, mussten jedoch im Sinne der Projektplanungsprozesse für die ganze Release konkrete Zusagen im
Vorhinein tägigen.

Der Fachbereich hatte zwar nicht die Verantwortung für Einhaltung der Zeitpläne, war aber stets dem Risiko von Verzögerungen, Qualitätsmängel und Budgetüberschreitungen ausgesetzt.

Neuer Status Quo

Der Release Management Prozess im agilen Kontext läuft bei der Bank heute ganz anders ab als noch vor wenigen Jahren:

Zu Beginn wird eine grobe Roadmap (zeitliche Einordnung der Lieferungspakete), zwar mit Meilensteinen und grob formulierten Feature-Paketen definiert, aber noch ohne konkrete Versprechungen zu machen.

Eine solche Roadmap dient der Orientierung und zur Abstimmung von Erwartungshaltungen. Die Planung der Kosten dafür basiert dann auf einer sehr groben Einschätzung, mit dem Ziel, mittelfristig dafür die Ressourcen und ein Budget zu reservieren. Es wird nicht mehr der Inhalt als zentraler Maßstab fixiert, sondern vielmehr wird ein Team reserviert und ein zeitlicher Rahmen gesetzt, in dem man dann nach und nach die Inhalte nach ihrer Wichtigkeit für das Geschäft umsetzt.

Ein Beispiel für den Detaillierungslevel eines solchen Feature-Paketes in dieser Roadmap der Bank ist die Videoidentifizierung neuer Kunden über die Website des Unternehmens, die heute bereits viele Banken zur Online-Kontoeröffnung einsetzen. Der Kunde muss nicht mehr in die Bankfiliale, sondern kann ein Foto seines Ausweises online hinterlegen, um dann über Videokonferenz vom Servicemitarbeiter der Bank identifiziert zu werden. Es geht dabei noch nicht ums Detail, sondern um das Verstehen der großen „Brocken“.

Die Feature-Pakete werden dann jeweils in einzelne User Stories heruntergebrochen – immer nur so viele, wie sich im folgenden Sprint (ein Entwicklungszyklus) nach Einschätzung des Entwicklungsteams auch tatsächlich umsetzen lassen.

Und nur diese User Stories werden im Detail in Bezug auf Zweck, Qualitätsansprüche, User- und Ergebnisbeschreibung ausdefiniert.

Dadurch verringert sich deutlich der Umfang und die Komplexität bei der Planung zu Beginn und die Umsetzung der jeweils wichtigsten neuen Features kann wesentlich früher begonnen werden.

Dem Kunden bzw. dem internen Business Partner wird bereits nach Ende des Sprints der aktuelle Stand der Software präsentiert. Qualitätsmängel, kurzfristige Wünsche zur Nachbesserung oder andere Änderungen finden unmittelbar im nächsten Sprint der gleichen Release Berücksichtigung. Damit kann viel schneller reagiert und korrigiert werden, was eine deutliche Erleichterung für die Zusammenarbeit bringt.

Risiko im Agilen Modell

Das Risiko in solch einem agilen Modell sind für alle Beteiligten deutlich reduziert. Die Abschätzung der Features und der davon abgeleiteten User Stories erfolgt nun über einen Zeitraum von 2-4 Wochen, je nach Team und Produkt.

Das Projekt- bzw. Scrum-Team kann nun kurzfristig viel genauere Aussagen zu dem Lieferstatus der Software treffen. Der mittelfristige Plan bleibt solange variabel, bis er zur konkreten Umsetzung definiert und fixiert wird.

Das erfolgt kurzfristig, weshalb man nun wesentlich besser auf kurzfristige Anforderungen des Marktes reagieren kann. Die Entwicklungsteams und Business Partner stehen in einem stetigen Austausch. Fehler oder Entwicklungen, die an den Vorstellungen des Kunden vorbeigegangen sind, können somit unmittelbar
im nächsten Sprint berücksichtigt oder korrigiert werden.

Was hat sich dabei im Bezug zu Planungshorizonten verändert?

Wenn durch das Arbeiten in kurzen Zyklen das Risiko für die beteiligten Entscheider durch die rasche Sichtbarkeit von Ergebnissen kleiner wird, werden Themen wie „Absicherung“ vor Fehlern und der damit verbundene Aufwand deutlich geringer. Man kann also schnell Ergebnisse sehen, daraus lernen und die Fehler korrigieren, lange bevor daraus für das Geschäft negative Auswirkungen entstehen können.

Wo man sich früher mit langfristiger Planung und fixer Zielsetzung abfinden musste, kann sich der interne Kunde jetzt auf die Dinge konzentrieren, die man konkret kennt und jetzt braucht. Man kann in kürzeren Abständen neue Features für den Markt umsetzen und benutzt die langfristige Planung und langfristige Zielsetzung, um Strategien organisationsweit grob abzustimmen. Allerdings muss (und kann) jetzt die mittel- und langfristige Planung laufend angepasst werden.

In dem konkreten Fall gehen nun sogar einzelne Vorstände regelmäßig zu Projektteams, um sich informell über den Entwicklungsstand informieren zu können. Es geht dabei nicht darum, eine Lenkungsausschusspräsentation zu erhalten, sondern in unkomplizierter Umgebung über den Zustand des Produktes berichtet zu bekommen und eventuell gleich dort Prioritätsänderungen für die Produktentwicklung anzuregen.

Wer hätte das vor wenigen Jahren noch in einem so großen Unternehmen erwartet?