Agiles Arbeiten – Wunderwaffe im Banking? 5 Thesen auf dem Prüfstand

Schneller, besser, transparenter: Agile wird häufig als Heilsbringer angepriesen, aber was können agile Methoden für Banken in einer hochregulativen Umgebung tatsächlich leisten? Eine realistische Einschätzung zu der Frage, ob sich die fünf zentralen Leitsätze in der Praxis bewährt haben.

In Zeiten von steigendem Wettbewerbsdruck ist es für Unternehmen wichtiger denn je, rasch auf veränderte Kundenbedürfnisse zu reagieren. Diesem Ziel hat sich das agile Arbeiten verschrieben. Das „Agile Manifest“ aus dem Jahr 2001 markiert den Beginn der Bewegung. 17 IT-Spezialisten und Softwareentwickler formulierten darin Werte und Prinzipien agiler Teams, die heute weit über die Grenzen der Softwareentwicklung hinaus bekannt sind. Das agile Manifest versucht den Kunden ins Zentrum zu stellen, indem der Entwicklungsprozess flexibler gestaltet wird – durch eigenverantwortliche Teamarbeit und einer Verringerung von Bürokratie. Bekannte IT-Firmen wie IBM, Spotify und Google entwickeln ihre Produkte dank agiler Methoden erfolgreich am Puls der Zeit.

Auch traditionelle Banken sind gefordert, immer schnellere und günstigere Lösungen zu entwickeln – und das bei höherer Qualität. Denn Fintechs wie N26 oder Revolut haben durch agile Methoden in kürzester Zeit ein vollkommen neues Kundenerlebnis geschaffen, was die Marktposition etablierter Banken bedroht. Als Reaktion darauf hat beispielsweise die ING kürzlich als eine der ersten europäischen Banken all ihre Organisationseinheiten auf agiles Arbeiten umgestellt. 

Agiles Arbeiten liegt im Trend – zurecht?

Hält Agile für den Bankensektor wirklich, was es verspricht? Die fünf gängigsten Argumente für agiles Arbeiten im Realitätscheck:

1. Agile reduziert die Entwicklungszeit

Mithilfe agiler Methoden wie Scrum oder Kanban sind Leistungen schneller verfügbar, außerdem werden Fehler rechtzeitig erkannt und behoben: So lautet eine zentrale Versprechung des agilen Arbeitens. Aber stimmt das wirklich? In der Praxis beobachten wir bei Banken häufig hybride Projekte. Zulieferer arbeiten oft noch klassisch nach dem Wasserfall-Modell. Je stärker die Bank von ihnen abhängig ist, desto mehr verzögern sich dadurch ihre Projekte. Kombinierte Projekte bringen mehr Komplexität mit sich; dies erschwert eine eindeutige Kommunikation innerhalb des Teams und weiterer Stakeholder, bspw. mittels Management Reportings. Um die Entwicklungszeit tatsächlich zu verkürzen, ist es  umso wichtiger, beiden Welten zusammenzuführen, sich insbesondere in der Übergangsphase den Bedürfnissen beider Seiten bewusst zu sein und sich nicht nur auf eine Methodik zu konzentrieren.

2. Agile führt zu effizienteren Teams

Jungen Unternehmen fällt es durch ihre Start-up-Kultur, flachen Hierachien und der hohen intrinsischen Motivation ihrer Mitarbeiter in der Regel leicht, agiles Arbeiten zu etablieren. Bei größeren Unternehmen steht Agilität zwar auch ganz oben auf der Agenda, die Umsetzung fällt jedoch deutlich schwerer. Traditionelle Strukturen, etablierte Prozesse und Führungsphilosophien stehen der agilen Transformation häufig im Weg. Konflikte zwischen der hierarchischen Linienorganisation und den dynamisch arbeitenden Projektteams sind keine Seltenheit.

Damit Agile wirklich effizientere Teams hervorbringt, müssen alle internen Stakeholder zunächst ein agiles Mind-Set entwickeln. Gleichzeitig gilt es, die Anreizsysteme auf die neue Methodik abzustimmen. Da sich agiles Arbeiten nicht über Nacht einstellt und Unternehmen mit zahlreichen Widerständen rechnen müssen, ist es ratsam, externen Experten hinzuzuziehen. Indem diese eine aktive Kommunikationsumgebung formen, können auch traditionelle Großunternehmen von einer höheren Team-Effizienz in agilen Projekten profitieren.

3. Agile generiert bessere Lösungen

Agile wird nachgesagt, nicht nur bessere Lösungen zu entwickeln, sondern auch die Kundenzufriedenheit zu erhöhen. Wie? Indem der unternehmensinterne Entscheidungszyklus reduziert wird, steigt die Innovationsgeschwindigkeit. Kürzere Go-to-Market-Zyklen ermöglichen einen aktiven Austausch zwischen Kunde und Unternehmen, wodurch die Produkte schneller und exakter an die Bedürfnisse der jeweiligen Zielgruppe angepasst werden können als bei Wasserfallprojekten. Soweit die Theorie. In der Praxis fordern sich schnell verändernde Produkte allerdings Interessenskonflikte heraus: Während das Projektteam flexibel auf neue Kundenerwartungen reagiert, befürworten Linienmitarbeiter tendenziell den Status Quo. In der Praxis sind Lösungen aus agilen Produkten nicht pauschal besser als ihre Wasserfall-Pendants. In einer erfolgreichen agilen Struktur können schlechte Lösungen jedoch früher erkannt und entsprechende Maßnahmen ergriffen werden.

4. Agile erhöht Transparenz und Planungssicherheit

Damit agiles Arbeiten funktioniert, muss der Status eines Projekts durch Whiteboards, tägliche Meetings und agile Software jederzeit einsehbar sein. So sind agile Projekte deutlich transparanter als klassische Verfahren. Es zeigt sich erfahrungsgemäß jedoch auch hier ein Problem: In Wasserfallprojekten sind Meilensteine inhaltlich und zeitlich klar definiert, so sind Zwischenergebnisse zu jedem Meilenstein sichtbar. Das Management ist hieran gewöhnt und erwartet somit auch in agilen Projekten ein zeitgebundenes Reporting mit entsprechenden Arbeitsergebnissen. Agile Projektteams überspringen aber teilweise die bekannten Meilensteine, um an ihr Ziel zu kommen. Das Management wittert häufig Projektrisiken und greift ein – was meist das Ende des agilen Arbeitens bedeutet. Um Vertrauen und Transparenz bis zum Management-Level zu schaffen, müssen bisherige Projekt-Hilfsmittel (z. B. Software, Reporting, Ausdrucke, MIS) an die agile Methodik adaptiert werden, um eine weitreichende Akzeptanz im Unternehmen zu gewährleisten.

5. Agile ist der klassischen Methodik immer überlegen

Diese Pauschalisierung ist mit Vorsicht zu genießen. Je strukturierter und routinierter die Aufgabe, desto eher bietet sich die Wasserfallsystematik an. Die agile Projektmethode eignet sich vor allem dann, wenn die IT-Komponente sehr dominant ist und das Projekt von einem hohen Maß an (inhaltlicher) Unsicherheit bestimmt wird, beispielsweise durch eine noch unklare Zieldefinition und Umsetzungsidee. Im Banking ist dies bspw. oft durch den Einfluss von regulatorischen Anforderungen oder aktuellen Marktentwicklungen zu sehen. Diese Änderungen an der Lösungsidee im Verlauf des Projekts sind im agilen Umfeld einfacher und schneller umzusetzen.

Fazit: Die genannten Thesen gelten nicht ohne Einschränkungen – die Erwartungen an Agile sind mitunter viel zu hoch. Agiles Arbeiten ist nicht per se schneller, besser, effizienter und transparenter. Zu hohe Erwartungen an agile Projekte gefährden die weitreichende Einführung dieser stellenweise überlegenen Projektmethodik. Ein pauschaler Heilsbringer im Banking ist sie jedoch nicht. Damit die Methodik ihr Potenzial entfalten kann, müssen Banken zunächst die passenden Rahmenbedingungen schaffen. Externe Experten mit Erfahrung in agilen Projekten helfen, Agile auch im Umfeld vonstellenweisem Widerstand im Unternehmen zu implementieren. Wenn das gelingt, können agile Methoden die an sie gestellten Erwartungen auch erfüllen.