GASTBEITRAG: Wieso agile Methoden im Banking keinen Sinn machen

Zwei Jahrzehnte habe ich bei Banken verbracht, in denen ich stabile, erfolgreiche Projekte geliefert habe. Jetzt ist der Zeitpunkt gekommen, an dem ich die Hand erhebe und sage, was gesagt werden muss: Agile Methoden und Banken passen nicht zusammen.

Sicherlich handelt es sich um keine populäre Position, schon gar nicht bei der neuen Generation von IT-Profis, dennoch müssen sie damit konfrontiert werden. Die meisten Banken geben vor, auf den fahrenden Zug aufzuspringen und das stellt einen großen Fehler dar. Spezialisten für agile Entwicklung, die bei einer Bank anfangen, drohen enttäuscht zu werden.

Die Wurzel des Problems besteht darin, dass Banken hoch regulierte und hierarchische Organisationen sind, wo die Anwender – üblicherweise Trader – kein wirkliches Interesse an der Teilnahme an täglichen Meetings haben, um den Fortschritt bei einem IT-Projekt zu diskutieren.

Doch dies funktioniert nicht mit agilen Methoden. Bei agilen Methoden handelt es sich um eine Reihe von Prinzipien, die eine Entwicklung erlauben, ohne dass ein Anforderungskatalog festgezurrt wird. Tägliche Meetings zwischen Scrum Mastern, Entwicklern und Product Ownern erlauben es ein Produkt sukzessive zu entwickeln. Theoretisch führt dies zu einem besseren Produkt. Das übliche Beispiel hierfür: Man beginnt mit dem Auto der Feuersteins und endet mit einem Ferrari.

Im Banking haben die „Product Owner“ aus dem Front Office nur eines zu sagen, wenn Sie sie darum bitten, an den täglichen Agile-Meetings teilzunehmen: „Hau ab.“ Dies führt dazu, dass die Meetings üblicherweise nur von einem Stellvertreter besucht werden, der nicht wirklich das Produkt verwendet.

Agile Methoden können sich auch auf Entwickler nachteilig auswirken. Wer jeden Tag gezwungen ist, in einem Meeting zu stehen und auf einen Post-IT-Zettel zu schreiben, was er erledigt hat, kann dazu gezwungen werden, flüchtig zu arbeiten und schlampige Arbeit abzuliefern, nur um etwas zu sagen. Dies ist im Banking besonders oft der Fall, wo viele Leute den Verlust ihrer Arbeitsplatzes fürchten und daher nicht als Unterperformer erscheinen wollen – auch wenn sie es gar nicht sind.

Noch wichtiger ist, dass Banken in einem hoch reguliertem Umfeld tätig sind. Wer ein Projekt in einer Bank umsetzt, musst ständig Checks durchführen und eine Dokumentation anlegen. Sie benötigen Dokumente zur Methode, Mitschriften von Meetings und ein Protokoll der getroffenen Lösungsmaßnahmen, wenn ein Problem eingetreten ist. Agile Methoden leisten das kaum.

Aber was funktioniert stattdessen? Beispielsweise die Wasserfallmethode von Prince2. Hier gibt es Zielvorstellungen, was und wie Sie es erledigen müssen. Es gibt einen Implementationsplan für die Leute, die es entwickeln. Und vor allem haben Sie Ihre RAID-Checkliste (Risiken, Annahmen, Probleme (issues) und Abhängigkeiten (dependencies), die auf jeder Stufe angewendet wird.

Ich behaupte keinesfalls, agile Methoden würden nicht funktionieren, sondern lediglich dass sie im Banking nicht funktionieren. Bei Agile handelt es sich um eine großartige Methode, wenn Sie eine Gruppe von Entwicklern sind, die ein Programm von Anfang an entwickeln und regelmäßig flexible Produkte wie etwa Amazon ausrollen. Doch wenn man in einer großen, sehr hierarchischen Organisation mit weit entfernten Anwendern und eifrigen Regulatoren arbeitet, dann kann das einfach nicht wie beabsichtigt funktionieren.

Es muss nicht eigens erwähnt werden, dass diese Erkenntnis langsam auch bei den Banken ankommt und sie vermehrt hybride Methoden wie agile und Wasserfall-Methodologien anwenden. Zwar macht das Sinn, doch auf die Puristen agiler Methodik kann dies wie ein Schock wirken, wenn sie wirklich glauben, dass sich Banken ernsthaft auf agile Methoden einlassen würden. Bank sind einfach nicht agil und werden es auch niemals sein. Das sollten Sie sich von Anfang an klar machen.

Bei Ranjan Kamath handelt es sich um ein Pseudonym.