Ausgangssituation

​Vor etwa zwei Jahren hat unser Kunde im Bankenumfeld ein Großprojekt zur Einführung eines neuen Kernbuchungssystems gestartet. Das Altsystem basiert auf einem über Jahrzehnte gewachsenen Hostsystem. Bis zur Einführung des neuen Systems sollten noch viele Monate vergehen. Für eine Endkundenanwendung zur Verwaltung von Vertragsdaten stand aber eines fest: Es nutzt viele alte Schnittstellen, die im Rahmen des Großprojekts abgelöst werden müssen. Für einige Anwendungsfälle gab es zum Zeitpunkt des Projektstarts allerdings schon moderne WebService-Schnittstellen in einer zentralen Middleware-Applikation, die den Zugriff auf verschiedene Backend-Systeme kapselte. Dabei handelte es sich im Wesentlichen um Kunden-/Geschäftspartnerstammdaten und Vertragsdaten, auf die nur lesend zugegriffen wurde. Für die restlichen Altschnittstellen existierten noch keine konkreten Schnittstellen im Neusystem.

Mit diesen Informationen fassten wir als Projektteam eine "verrückte" Idee. Wir starten ein agiles Projekt. Beim eher konservativ eingestellten Middle-Management kamen allerdings Bedenken im Hinblick auf die Einhaltung der Compliance-Vorgaben1 durch das Vorgehen auf. Es musste also ein Kompromiss gefunden werden:

Wir starteten ein agiles Vorgehen in einem klassischen Wasserfall-Projekt. Kann das funktionieren?

Um die Antwort vorwegzunehmen: Es hat funktioniert, recht gut sogar. Wir mussten allerdings ein paar Restriktionen in Kauf nehmen.

Das Projektteam bestand aus vier Entwicklern (Development Team), einem Business Analysten (Product Owner), dem Autor dieses Artikels, der sich das ganze ausgedacht hat (Scrum Master), dem offiziellen IT-Projektleiter und dem fachlichen Projektleiter.

Die erste Herausforderung war die Besetzung der entsprechenden Rollen nach Scrum. Die Personen des Development Teams waren offensichtlich. Der Scrum Master war ebenfalls schnell gefunden. Die Besetzung des Product Owners stellte uns vor Herausforderungen. Da wir zunächst keine fachlichen Themen zu bearbeiten hatten, sondern es primär um technische Schnittstellenwechsel ging, war der fachliche Teilprojektleiter nicht gut geeignet. Glücklicherweise hatten wir noch einen organisatorisch versierten Business Analysten im Team. Dieser hat sich prompt davon überzeugen lassen, das Product Backlog zu verwalten und die Sprint Plannings zu organisieren und zu moderieren. Offen blieb zu diesem Zeitpunkt noch die Rolle des IT-Projektleiters. Dieser hat die klassische Projektleitungsrolle wahrgenommen und für das Scrum Team im Hintergrund die Fäden gezogen - immer in enger Abstimmung mit Product Owner und Scrum Master. Somit wurde dem Scrum Team der Rücken freigehalten und die Mitglieder konnten sich um die Inhalte und Umsetzungen kümmern.

Kompromisse

Natürlich mussten wir weitere Kompromisse eingehen. Wenn man sich in einem Vorgehen nach Wasserfallmodell bewegt, unterliegt dieses bestimmten Phasen²:

1. Vorhaben initiieren
2. Konzeption erstellen
   1. Grobkonzept
   2. Feinkonzept
3. DV-Design erstellen
4. Lösung realisieren und testen
   1. Realisierung
   2. Systemintegrationstest
   3. Releaseintegrationstest
5. Betriebseinführung

An diese Phasen war das Projekt natürlich gebunden. Wir haben allerdings einen gewissen Spielraum ausgenutzt:

Die Phasen Konzeption erstellen, DV-Design erstellen und Realisierung haben wir zu einer großen Phase zusammengefasst und in Sprints aufgeteilt. Mit den Compliance-Verantwortlichen konnte eine Sonderregelung bzgl. der jeweiligen Quality Gates gefunden werden, wie nachfolgende Grafik veranschaulicht.

Die Phasen

• Grobkonzept
• Fachfeinkonzept
• DV-Design
• Realisierung 

werden zusammengefasst und in mehrere Sprints unterteilt.

Release Planung

Zu Beginn haben wir festgelegt, dass zu bestimmten Release-Terminen (geplante Major-Releases im Gesamtunternehmen) gewisse Änderungen in die Produktion ausgerollt werden sollen.

Wir haben also eine grobe Aufwandsschätzung für die verschiedenen Themen durchgeführt:

1. Neugestaltung des internen Service-Schnitts auf eine fachliche Ausrichtung
2. Lesen von Kunden-/Geschäftspartnerdaten über WebService-Schnittstelle
3. Ändern gewisser Kundendaten
4. Lesen von Vertragsdaten

Die Punkte 1-3 sollten nach einem halben Jahr Entwicklung und Test produktiv gesetzt werden. Der Punkt 4 sollte ein paar Monate später folgen.

In einem Workshop haben wir dann initial in JIRA ein Product Backlog angelegt und in einem Planning Poker³ die groben Aufwände in Personentagen beziffert. Auf Basis der zur Verfügung stehenden Ressourcen konnten wir damit eine langfristige Release-Planung erstellen.

Anschließend startete direkt der erste zweiwöchige Sprint, mit dem Sprint Planning am Montag. Für alle Beteiligten war das komplett agile Vorgehen eine neue Welt. Die Daily Stand Up-Meetings waren hingegen bereits bekannt, das hatten wir schon in vergangenen Projekten etabliert. Die veränderte Arbeitsweise mit dem Sprint Board und dem Pull-Prinzip für Tasks brauchte anfangs noch ein wenig Umdenken. Das war allerdings nicht weiter schlimm, denn wir wollten ja "groß denken, aber klein anfangen". Diese Strategie hatte rein psychologisch einige Vorteile: Den Beteiligten wurde die Angst vor zu viel Neuem auf einmal genommen und gleichzeitig auch zugelassen, dass sich die Team-Mitglieder ein wenig ausprobieren können. Anfangsfehler wurden bewusst in Kauf genommen, um einen Lerneffekt zu generieren.

Am Ende eines jeden Sprints erfolgte natürlich das Review. Dieses hat leider nicht so viel Anklang bei potentiellen Review-Teilnehmern gefunden. Den Vertretern des Fachbereichs zu präsentieren, dass alles genau wie vorher ist, nur unter der Haube der Weg der Daten ein anderer ist, stößt leider nicht auf ganz so viel Interesse. In Retrospektiven haben wir verschiedene Ansätze zur Aufwertung des Reviews besprochen und hatten hier auch Teilerfolge.

Nach den ersten acht Sprints war es dann soweit und der Systemtest (Sprint 9) begann. Jetzt wurde die Latte etwas höher gelegt, denn neben der Weiterentwicklung für das Folgerelease mussten auch Fehler behoben werden. Das hat die Sprint-Planung leider ab und zu ins Wanken gebracht und die Sprint-Ziele konnten nicht immer erreicht werden. In den Sprints mit einem hohen Bugfix-Bedarf, haben wir gemeinsam mit dem Team die wichtigsten inhaltlichen Themen umgesetzt und die nicht umgesetzten Themen in den nächsten Sprint geschoben. Dank ausreichend Puffer konnten beide Releases letztlich erfolgreich durchgeführt werden.

Wie es beispielsweise auch beim Modell des agilen Festpreises⁴ angewendet werden kann, wurde letztlich nicht gänzlich der ursprünglich geplante und geschätzte Scope umgesetzt. Im Rahmen der Sprint-Arbeiten sind neue, wichtigere Themen aufgekommen und wurden im Product Backlog aufgenommen. Diese wurden dann in Folgesprints durch weniger wichtige Tasks ausgetauscht. Ein Beispiel hierfür war die Erweiterung eines bestehenden Vertragsdatenservices um zusätzliche Daten. Dafür haben wir einige Optimierungen an der Datenbankzugriffsschicht noch nicht realisieren können.

Wir sprinten übrigens immer noch!

Nach dem zweiten Release-Termin hatten wir also alles rund um die Kunden-/Geschäftspartnerdaten ausgetauscht und das Lesen von Vertragsdaten gegen die bestehenden WebService-Schnittstellen geschwenkt. Für einige weitere fachliche Prozesse wurden allerdings immer noch alte COBOL-Transaktionen aufgerufen. Die Welt um uns herum hat sich in der Zwischenzeit allerdings weitergedreht und die Einführung des neuen Kernbuchungssystems wurde bestätigt. Somit konnte unmittelbar mit der Anbindung der ersten neuen Schnittstellen begonnen werden. Da daraufhin auch Anpassungen an den fachlichen Prozessen unausweichlich waren, konnte glücklicherweise auch die Zusammenarbeit mit dem gleichen Fachbereich intensiviert werden.

Vor- und Nachteile im Überblick

Natürlich hat dieses hybride Vorgehensmodell neben vielen Vorzügen auch einige negative Aspekte. Hier einige Punkte, die sich im Nachhinein manifestiert haben:

​Vorteile	​Nachteile
​Das Scrum Team und alle weiteren Projektmitglieder konnten sich im Sprint-Rhythmus immer sehr stark auf einige wenige Aspekte fokussieren und diese im Detail beleuchten, planen und durchführen. ​	​​​​​Die "Steuerung" des Gesamtvorhabens ​ist nicht unbedingt trivial, insbesondere wenn man auf feste Release-Termine hinarbeitet. Hier konnten wir durch regelmäßigen Austausch mit Product Owner, Scrum Master und IT-Projektleiter jedoch gut den Verlauf aus den Erfahrungen der vergangenen Sprints auf die Zukunft reflektieren und gemeinsam Lösungen für die Probleme finden. ​
​Durch die Sprints war es möglich, die Fachkonzeption und das DV-Design iterativ im Zusammenspiel mit der Bearbeitung der Sprint-Themen fortzuschreiben. ​	​Die Schätzung von Task in Story Points war teilweise nicht einfach und treffsicher, da es wenige ähnliche Aufgaben gab. Daher war ein Vergleich mit vergangenen Tasks nicht möglich. Dieser Punkt ist zu relativieren, da nicht bekannt ist, wie exakt eine Schätzung in Personentagen ausgefallen wäre. ​
​Die Ereignisse Sprint Planning und Sprint Review haben dazu geführt, dass Stakeholder (Fachseite, Systemintegratoren, Applikationsbetrieb, etc.) in regelmäßigen Abständen über den Fortschritt des Vorhabens informiert wurden und direkt Feedback geben sowie Anforderungen anmelden konnten. ​	​Wie bereits im ersten Punkt zu erkennen, eignet sich ein agiles Vorgehen deutlich besser, wenn man keine Projekte durchführt, sondern mit einem festen Team kontinuierlich an der Entwicklung eines Produktes arbeiten kann und dieses dann auch in eigener Regie produktiv bringen kann. ​
​Allein die Tatsache, dass in das Projektgeschäft ein frischer Wind eingezogen ist, hat viele Beteiligte beflügelt. Somit ist rasch eine konstruktive und harmonische Team-Atmosphäre entstanden. ​	​
​Im Laufe der Sprints konnten Tasks dem Product Backlog hinzugefügt und andere herunter priorisiert werden. Ein aufwändiger CR-Prozess wurde nicht benötigt. ​	​

Wie bereits im Artikel skizziert, soll diese Gegenüberstellung keinen vollständigen Kriterienkatalog darstellen, sondern stellt nur die rückblickend markantesten Aspekte heraus. Insbesondere haben die Entwickler sich an diese Vorgehensweise sehr gewöhnt und sie schätzen gelernt.

Fazit

Die Einführung eines neuen Vorgehens hatte zu Anfang viele Reize aber auch einige Gefahren und Stolpersteine. Letztlich habe ich eins gelernt: Es geht nur gemeinsam! Wenn ein Team gemeinsam für eine Sache begeistert ist, dann ist vieles möglich. Hier bin ich auch heute noch meinem Team sehr dankbar, dass wir gemeinsam diesen Weg gehen und ausprobieren konnten.

Und ja - ich würde es immer wieder tun.