Herausforderungen der Agilität in Banken:

Agile Methoden wie Scrum und Kanban sind in der Softwareentwicklung fest etabliert, doch in der Bankenwelt stehen sie vor erheblichen Hürden. Ein zentrales Problem ist der Widerspruch zwischen der traditionell hierarchischen Unternehmensführung und der Flexibilität, die agiles Arbeiten erfordert. Viele Banken haben agile Ansätze eingeführt, stoßen jedoch häufig auf interne Widerstände. Die starren Strukturen, die nötigen Kulturveränderungen und die oft festgefahrenen Erwartungen des Managements und der Mitarbeiter stellen erhebliche Herausforderungen dar. Dies führt zu Phänomenen wie „Fassaden-Scrum“ oder „Pseudo-Scrum“, die die Schwierigkeiten treffend beschreiben.

Besonders der Product Owner, der die Anforderungen und die Vision des Fachbereichs ins Team tragen soll, steht häufig vor einer erheblichen Doppelbelastung: Neben seinen Aufgaben im agilen Team wird er weiterhin stark im Tagesgeschäft beansprucht. Diese Doppelrolle führt dazu, dass POs ihre zentrale Funktion oft nicht optimal ausfüllen können.

Hinzu kommt, dass vielen POs die notwendige technische Expertise fehlt, um Anforderungen in klare, umsetzbare User Stories zu übersetzen und eine konsistente Produktvision zu entwickeln. Dies stellt eine enorme Herausforderung dar, insbesondere da POs in der Regel nur wenig bis keine Berührungspunkte mit der Softwareentwicklung hatten. Von ihnen wird erwartet, eine Vision für ein technisches Produkt zu schaffen, was selbst für erfahrene Entwickler oder Entwicklerinnen oft schwierig ist. Die Problematik liegt auf der Hand: Der Product Owner soll Brücken zwischen den Fachbereichen und der IT schlagen, ohne jedoch über das nötige technische Fundament zu verfügen.

Ein weiteres Hindernis stellt die agile Meetingkultur dar, die in vielen Banken als belastend empfunden wird. Daily Scrums, Sprint-Planungen und Retrospektiven, die essenziell für den Erfolg agiler Projekte sind, werden in konservativen Bankenumgebungen oft als unnötiger bürokratischer Aufwand wahrgenommen. Viele Mitarbeitende empfinden die hohe Frequenz der Meetings als zeitraubend und ineffizient, was häufig zu einer ablehnenden Haltung gegenüber agilen Methoden führt – statt die Meetings als Werkzeuge zur Förderung von Transparenz und Kommunikation zu nutzen.

Zuletzt ein besonderes Problem: Die Budgetplanung. Banken arbeiten traditionell mit festen Jahresbudgets und klar definierten Meilensteinen, was in direktem Widerspruch zum agilen Ansatz steht, der auf iterative Entwicklung und Flexibilität gegenüber Veränderungen setzt. Eine häufig gestellte Frage, wie „Wann ist die Software fertig?“, lässt sich in einem agilen Team nur schwer zu Beginn eines Projekts beantworten. Diese Unsicherheit stößt auf Skepsis im Management, das auf präzise Zeitpläne und verlässliche Kalkulationen angewiesen ist, um Ressourcen zu steuern und Projekte zu überwachen. Diese Diskrepanz zwischen traditioneller Planung und agiler Flexibilität stellt eine erhebliche Hürde dar, die es zu überwinden gilt.

Lösungen zur Umsetzung von Agilität in Banken:

Trotz der genannten Herausforderungen gibt es praktikable Lösungsansätze, um agile Methoden erfolgreich in Banken zu implementieren.

Ein zentraler Ansatz besteht darin, die Rollenverteilung klar zu strukturieren und den Product Owner (PO) gezielt zu unterstützen. Hier kann die Integration eines technischen „Partners“ im Team, wie beispielsweise eines Solution Architects oder Technischen Product Owners (der Name der Rolle ist egal), eine entscheidende Entlastung bieten. Diese Rolle übernimmt die wichtige Aufgabe, die Anforderungen des Fachbereichs in verständliche und umsetzbare User Stories zu übersetzen und fungiert als Schnittstelle zwischen Fachbereich und Entwicklungsteam. Zudem arbeitet dieser technische Partner gemeinsam mit dem PO an der Entwicklung einer klaren Produktvision.

Durch diese Zusammenarbeit wird der Product Owner nicht nur entlastet, sondern auch strategisch unterstützt, was eine zielgerichtete und effiziente Umsetzung der Anforderungen ermöglicht. Der PO kann sich stärker auf seine Hauptaufgabe – die Priorisierung und Kommunikation der Geschäftsanforderungen – konzentrieren, während der technische Partner die Brücke zur IT und den technischen Details schlägt.

Eine Möglichkeit besteht darin, Meetings wie das Sprint Planning und das Sprint Review zusammenzulegen. Dies könnte den zeitlichen Aufwand verringern, ohne die grundlegenden Prinzipien der agilen Arbeitsweise zu gefährden. Darüber hinaus können Anpassungen bei der Frequenz der Meetings oder der Zusammensetzung der Teilnehmer vorgenommen werden. Dadurch lässt sich der Meetingaufwand optimieren, während gleichzeitig die wesentlichen Vorteile wie verbesserte Kommunikation und Transparenz im Team erhalten bleiben. Solche maßgeschneiderten Anpassungen ermöglichen es, den spezifischen Anforderungen und Strukturen in Banken gerecht zu werden, ohne die Effektivität der agilen Methoden zu beeinträchtigen.

Die Herausforderung der agilen Budgetplanung lässt sich ebenfalls bewältigen, indem vor Projektbeginn die Prioritäten der einzelnen Features für jede Version klar definiert werden. Konzepte wie das Minimum Viable Product (MVP) können dabei äußerst hilfreich sein, um den Fokus auf die wichtigsten Funktionalitäten zu legen. Sobald das Team einen technischen Plan ausgearbeitet und eine erste Schätzung der Features vorgenommen hat, wird wie gewohnt ein Puffer von etwa 200-300% hinzugefügt, um unvorhergesehene Ereignisse abzudecken.

Im Anschluss setzt sich das Team mit dem Fachbereich zusammen, um die Prioritäten der Features zu überprüfen und diese auf einer groben Zeitleiste zu planen – anstelle von festen Meilensteinen. Dieser Ansatz ermöglicht es, realistische Erwartungen zu setzen, ohne die Flexibilität des Teams durch starre Stichtage einzuschränken. Gleichzeitig bleibt ausreichend Spielraum für Anpassungen, da die Prioritäten im Verlauf des Projekts regelmäßig neu bewertet werden können. Das ist besonders wichtig, da während der Projektarbeit häufig neue Anforderungen entstehen oder zusätzliche Erkenntnisse gewonnen werden, die eine Anpassung der Planung und Prioritäten erforderlich machen. Auf diese Weise wird eine dynamische und anpassungsfähige Planung gewährleistet und am Ende der Projektdauer, hat der Fachbereich eine laufende Software mit den wichtigsten Funktionen.

Schlusswort

Agilität in Banken kann erfolgreich sein, wenn eine ausgewogene Balance zwischen traditionellen Strukturen und agiler Flexibilität gefunden wird. Dies erfordert nicht nur Geduld und Erfahrung, sondern auch das nötige Know-how von Mitarbeitenden, die sowohl mit agilen Methoden als auch mit der spezifischen Arbeitsweise einer Bank vertraut sind. Die Bereitschaft, bestehende Prozesse schrittweise zu hinterfragen und den Willen zur Veränderung mitzubringen, ist entscheidend.