Reality Check

„Ha!“ höre ich die erfahrenen Projektleiter rufen. „Um das zu verhindern gibt es ja agile Methoden!“ Richtig! Ein wesentlicher Vorteil agiler Projektdurchführung ist das frühzeitige und kontinuierliche Feedback. Das soll sichtbar machen, ob die Projektergebnisse anklang finden oder nicht. „Fail fast“ heißt hier die Maxime. Sind Anwender schon während des Projektes nicht zufrieden mit dem, was das Projekt produziert, kann frühzeitig gegengesteuert werden. So soll verhindert werden, dass viel Geld in ein Projekt investiert wird, das sich am Ende als Fehlschlag herausstellt.

Ganz so einfach ist es jedoch leider nicht, wie ich kürzlich am Beispiel eines Softwareprojektes bei einer deutschen Großbank feststellen konnte. Diese Bank hat sich das ehrgeizige Ziel gesetzt, ein Altsystem zu modernisieren. Dazu sollte ein einheitliches Interface geschaffen werden, das sowohl Kunden als auch Bankberater nutzen und sich lediglich im Funktionsumfang unterscheidet. Den Auftrag für die Realisierung erhielt die eigens von der Bank gegründete „Digital Factory“, die sich in bester Startup-Manier ans Werk machte.

Nach einigen Monaten wurde dann feierlich das erste Release angekündigt. Doch die Enttäuschung war groß. Zwar war das Interface der neuen Software auf der Höhe der Zeit und ließ sich nun selbst auf Tablets ausführen. Allerdings bot die Applikation lediglich einen Bruchteil der Funktionalität des Altsystems. Nach einigen Tagen war klar, dass die Software im aktuellen Zustand für die professionellen Ansprüche der Bankberater nicht geeignet war.

Wie konnte das passieren? Schnell war klar, der Fehler lag nicht im agilen Vorgehen. Hier hatte man in der Digital Factory alles richtig gemacht. Was fehlte war ein effektives Erwartungsmanagement. Die Bankberater gingen davon aus, dass mit dem neuen System das Altsystem obsolet werden würde und erwarteten einen äquivalenten Funktionsumfang. Für das Entwicklerteam war jedoch klar, dass dies nur nach vielen weiteren Releases der Fall sein kann, denn niemand kann erwarten, dass ein Altsystem, das über Jahrzehnte gewachsen ist, nach ein paar Sprints vollständig durch ein neues System abgelöst werden kann. Leider hatte man es aber versäumt, das der Anwendergruppe der Bankberater zu vermitteln.

Der Protest der Bankangestellten war so heftig, dass man in der Bank panisch reagierte und das Projekt auf Halt setzte. Anstatt das „fail fast“ als Kernbestandteil der Methode zu akzeptieren und entsprechend zu reagieren, stellte man die agile Herangehensweise als Ganzes in Frage. Aus der Panik heraus hat man sogar den eigentlich sinnvollen Digital Factory Ansatz gänzlich eingestellt und die Softwareentwicklung in die Hand der altehrwürdigen IT Abteilung gegeben. Es darf bezweifelt werden, ob das dem weiteren Projektverlauf förderlich ist.

Für mich ist dieser Fall ein gutes Beispiel dafür, was passieren kann, wenn klassische und agile Projektmethoden unabgestimmt und unkoordiniert aufeinandertreffen. Dazu kommt, dass „agil“ weiterhin das Buzzword schlechthin in deutschen Managementetagen ist, häufig ohne dass auch nur ansatzweise verstanden wurde, was Agilität bedeutet und wo sie Sinn macht. Deshalb bin ich mir sicher, dass das hier geschilderte Beispiel nicht das letzte dieser Art sein wird, das wir in den nächsten Jahren noch beobachten werden.