Erste Ansätze des agilen Projektmanagements entstanden im Laufe der 1990er Jahre und wurden 2001 im sogenannten agilen Manifest beschrieben. Vier Werte bilden die Basis: Individuen und Interaktionen, funktionierende Software, Zusammenarbeit mit dem Kunden und das Reagieren auf Veränderung. Der Ursprung liegt in der Softwareentwicklung, in der Projekte oft von flexiblen Zielen (Scopes) geprägt sind. In der Praxis stellen Scrum und Kanban die wohl am häufigsten eingesetzten Methoden dar. Im Unterschied zum klassischen Wasserfall-Prinzip mit der Erstellung des Fachkonzepts, der folgenden Abstimmung des Fach-Feinkonzepts und der anschließenden Entwicklung ist die Vorgehensweise im agilen Projektmanagement gekennzeichnet durch ein iteratives, inkrementelles Vorgehen. Das Projekt wird in zeitliche Etappen (Iterationen) unterteilt. Am Ende jeder Etappe steht ein Produktteil, d.h. ein in sich abgeschlossenes Zwischenprodukt, das dem Kunden zum Feedback vorgelegt wird. Aus der Rückmeldung des Kunden entwickelt das Team dann gemeinsam wieder und wieder die nächste Iteration. Daraus resultiert eine kumulative Produktreife. Vereinfacht gesagt: Das Ziel ist die Reise von A nach B. Zuerst mit dem Skateboard, dann mit dem Fahrrad, später mit dem Auto etc.
Banken sind alles, nur nicht agil
Das Bankenumfeld weist allerdings einige Eigenheiten auf, die durch agiles Vorgehen allein nicht gelöst werden können. Ein Beispiel: Es besteht eine klare Anforderung des Regulators, gewisse Standards zu einem fixen Zeitpunkt einzuführen. Die Anforderung ist derart bindend, dass es bei einer Verfehlung zu massiven Sanktionen kommen kann. Das Projektergebnis muss hierbei oft von Legal, Compliance oder auch externen Prüfern schon abgenommen und geprüft sein, bevor eine Entwicklung begonnen hat. Hier wird das Projektziel durch ein Fachkonzept detailliert beschrieben und geprüft. Ein iteratives Vorgehen bietet sich nicht an.
Banken werden in der heutigen Zeit vor zahlreiche Herausforderungen gestellt, die sich aus den erhöhten Anforderungen durch Regulatorik und neue Wettbewerber (PayPal, Amazon & Co.), aber auch aus Kundenansprüchen ergeben. In vielen Häusern wird, mehr oder weniger, seit einiger Zeit eine Transformation hin zu einer agilen Organisation eingeschlagen. Nach Management-Aussagen will man „agil“ werden, denn die vermeintlichen Vorteile liegen auf der Hand – durch agiles Vorgehen soll alles schneller und effizienter gehen. Aber ist Agilität die Antwort auf alle Herausforderungen?
Die Vorteile, wie schneller Time-to-Market, flexible Anpassungen an den Scope und effizientere Ressourcenallokation, lassen es vermuten. Häufig weist die Organisation bei Banken durch ihre Historie alles Mögliche auf – nur nicht Agilität. So gibt es drei große Handlungsfelder, die bei der Transformation auf agile Arbeitsweisen beachtet werden müssen.
IT-Infrastruktur
Ein wichtiger Teilaspekt agiler Methodik ist die „Lieferung“ eines Zwischenproduktes. Diese Softwarekomponente muss in regelmäßigen Abständen an die Stakeholder ausgerollt werden. Dieser Prozess muss von der IT-Infrastruktur her möglich sein. Veraltete und komplex verwobene Systemlandschaften bedingen hohe Testaufwände und Vorlaufzeiten. Dadurch finden bei großen Instituten oft nur wenige Deployments jährlich statt. Ergo müssen zum einen eine Erneuerung der IT-Infrastruktur und zum anderen eine Verkürzung der Entwicklungszyklen, bestenfalls hin zum automatisierten „continous deployment“, erfolgen.
Personal, Hierarchie und neue Rollen
Die Organisation in echten agilen Teams kommt quasi ohne disziplinarische Vorgesetztenfunktion aus. Der Product Owner (PO) hat typischerweise die fachliche Führung inne. Das Team agiert als Ganzes und organisiert seine Arbeit und Iterationsziele gemeinsam und ohne konkrete Managementvorgabe. Dadurch verändern sich die Rollen der Beteiligten – der ITler bekommt mehr Einfluss auf das Produkt, der Projektmanager wird mehr Organisator etc. Diese disruptiven Veränderungen durch die Anforderungen der neuen Rollen sind so gravierend, dass unter Umständen nicht alle bisherigen Mitarbeiter diesen Weg mitgehen können oder wollen. Agiles Vorgehen verlangt ein starkes Umdenken der Mitarbeiter und punktuell sogar neue Impulsgeber.
Umstellung des gesamten Unternehmens
Häufig werden in Banken aktuell einzelne Projekte oder Bereiche transformiert, damit dort Agilität Einzug halten kann. Doch trotz dieser „Inseln“ bleibt die Bank oft in ihren alten Strukturen gefangen, und die Vorteile agiler Arbeitsweisen gehen durch Managemententscheidungen „von oben“ und weiterhin starre Hierarchien verloren. Durch diese Heterogenität innerhalb der Bank werden Kommunikation und Prozesse negativ beeinflusst.
Aber sollte trotz dieser Risiken auf die Vorteile verzichtet werden und agiles Projektmanagement für Banken als nicht darstellbar bewertet werden? Die Antwort ist klar: Nein, denn nur Banken, die sich den heutigen immer schneller ändernden Ansprüchen der Kunden und den Angriffen der Wettbewerber stellen können, haben eine Zukunft.
