Agile IT-Entwicklung und trotzdem revisionssicher - diesen Spagat trauten sich 2010 nur drei Prozent der befragten Banken zu. Inzwischen sind die anderen Institute nachgezogen. Die Mehrheit (71 Prozent) hat in den vergangenen drei Jahren damit begonnen, auf agile Methoden umzustellen. Die Verweigerer von einst entwickeln sich zu wahren "Scrum Mastern". 86 Prozent der Institute, die heute agil arbeiten, schätzen das eigene Know-how zu agilen Vorgehensmodellen als ordentlich bis hoch ein. Das sind Ergebnisse der Studie "Agile Methoden" der PPI AG, für die IT-Experten und -Entscheider aus 35 Banken befragt wurden*) .
Klassische Projektmethoden stoßen an ihre Grenzen
Die Bankenbranche stand lange Zeit mit agilen Vorgehensmethoden auf Kriegsfuß. Agil galt als Synonym für unsicher. Scrum (die agile Softwareentwicklung) war aus Sicht vieler Bankentscheider vollkommen ungeeignet, um sichere Softwarelösungen gemäß geltenden regulatorischer Anforderungen zu entwickeln. Dieses Vorurteil hat sich in den Instituten über Jahre gehalten, bis sich im Finanzsektor herumsprach, dass sich mit agilen Vorgehensweisen auch regulierungskonforme und stabile Software entwickeln lässt.
Für diesen Lerneffekt sorgten verschiedene Entwicklungen.
- Eine ist, dass Projekte immer komplexer werden, wodurch klassische Projektmethoden an ihre Grenzen stoßen.
- Zudem ist die Geschäftswelt deutlich dynamischer und weniger vorhersehbar geworden, und Banken mussten aus Erfahrungen der anderen Branchen sowie aus Pilotprojekten erkennen, dass agile Projekte häufig günstiger und schneller sind als klassische Ansätze. Durch agile Methoden lassen sich neue oder geänderte Anforderungen zeitnah umsetzen. Eine einsatzfähige Grundversion steht bei agilen Projekten bereits nach Wochen zur Verfügung, nicht nach Monaten. Das senkt das Risiko teurer Überraschungen am Ende des Projekts.
Hoher Schub durch die Digitalisierung
Die Digitalisierung im Bankenmarkt hat dem Erfolg agiler Methoden enormen Schub gegeben. Auf die IT-Abteilungen der Banken prasselt derzeit eine Masse digitaler Projekte ein. Beratung via Co-Browsing und Robo-Advice, Kontoeröffnung mit Smartphone und Video-Identifizierung sowie Online-Bezahlverfahren wie Paydirekt sind vier Beispiele von vielen.
Die IT-Architektur der Banken muss dafür digitale Prozesse über sämtliche Zugangskanäle unterstützen, also sowohl auf mobile IT, Web-Plattformen sowie bankinterne Zugriffe. Kunden und Bankberater müssen zudem über alle Kanäle zuverlässig auf Services zugreifen können. Die Kunden erwarten neue Dienste in Internetgeschwindigkeit, sprich: im Monats- oder Wochentakt. Diese hohe Taktung, plus die Vernetzung der Kanäle, machen die IT-Entwicklung komplex. Das sind zwei Faktoren, die stark für den Einsatz agiler Methoden sprechen.
"Geliefert wie bestellt" funktioniert häufig nicht mehr
Neben dem Digitalisierungsdruck und der zunehmenden Geschwindigkeit der Umsetzung müssen die Projektbeteiligten mit mehr Unsicherheiten zurechtkommen. Anforderungen können sich im Projektverlauf mehrmals ändern. Ausführliche Fachkonzepte, die alle Details des Produkts von Anfang bis Ende erfassen, sind in der Regel nicht mehr praktikabel. Die Fachseite weiß häufig zu Beginn der Entwicklung noch nicht genau, welches die finalen Anforderungen sind. Das Wasserfallprinzip "geliefert wie bestellt" funktioniert hier nicht mehr.
Die Projekte müssen so konzipiert sein, dass die Entwickler im laufenden Projekt Änderungen zeitnah umsetzen können. Darüber hinaus bietet es sich an, Anforderungen nach dem höchsten Business Value zu priorisieren und nicht danach, was sich am schnellsten umsetzen lässt.
Regulierung zwingt zum Umdenken
Die Flut regulatorischer Anforderungen leistet ebenfalls einen Beitrag dazu, dass Banken beim Organisieren von IT-Projekten agiler werden müssen. Vorschriften wie BCBS 239 beinhalten neue Anforderungen an das Reporting, wobei der Prozess der Gesetzgebung für die Institute schwer kalkulierbar ist. Die neue Wohnimmobilienkreditrichtlinie und die MaRisk-Novelle 2016 sind ähnlich gelagerte Fälle.
Last-Minute-Änderungen sind bei regulatorischen Vorgaben keine Seltenheit. Inhalte regulatorischer Vorschriften stehen nicht von Vornherein fest. Banken als Betroffene erhalten häufig die Gelegenheit, die Entwürfe zu kommentieren und im laufenden Verfahren Anpassungen durchzusetzen. Um die Vorgaben fristgerecht umsetzen zu können, müssen sie teilweise schon mit der Umsetzung beginnen, obwohl die nationale Gesetzgebung noch läuft. Klassische Projektvorgehensmodelle stoßen hier an ihre Grenzen.
Fintechs machen Scrum und Co. salonfähig
Digitalisierung und Regulierung führen damit zu einem Umdenken in der Projektorganisation bei den Banken. 37 Prozent der befragten Institute organisieren IT-Entwicklungsprojekte mittlerweile nach Scrum. 29 Prozent setzen auf Kanban. Aber auch andere Vorgehensweisen wie Feature Driven Development und Crystal haben ihre Anhänger.
Für reichlich Anschauungsmaterial und Bewegung sorgen die Fintechs als Wettbewerber und immer häufiger auch als Kooperationspartner der etablierten Banken. Nicht selten beteiligen sich klassische Geldinstitute auch an Start-ups, um dazuzulernen. Diese haben das agile Vorgehen perfektioniert und entwickeln sogenannte Minimum Viable Products. Sie schauen sich an: "Was ist der Nukleus an Funktionalität, der gebraucht wird, um eine Anwendung oder eine Leistung lauffähig zu bekommen" und setzen das in schnellem Tempo um. Alle anderen Funktionen kommen in späteren Sprints dazu. Ein Beispiel ist die gesetzliche Kontowechselhilfe. Einige Fintechs konnten die Pflichten aus dem Zahlungskontengesetz deutlich schneller umsetzen als die Banken.
Fehlerakzeptanz bei Kunden gestiegen
Darüber hinaus haben die Fintechs dazu beigetragen, dass die Fehlerakzeptanz bei den Kunden gestiegen ist. Benutzer moderner Apps erwarten in der Version 1.0 keine drastische Nullfehlerrate, wie sie Banksoftware klassischerweise liefert - zumindest, was grundsätzlich verzeihbare Fehler wie eine fehlende Optimierung auf mehrere Endgeräte oder eine umständliche Benutzerführung betrifft. Diese niedrigere Erwartungshaltung hat sich mittlerweile auf die etablierten Institute übertragen. Davon profitieren die Banken: Sie geben nun ihre Ressentiments gegenüber neuen Projektmanagementmethoden auf, trauen sich mehr zu und experimentieren ohne erhöhtes Risiko, dass Kunden beim kleinsten Darstellungsfehler in der Oberfläche sofort das Weite suchen.
Dabei ist es kein Widerspruch, dass die Version 1.0 keine Sicherheitslücken enthält. Im agilen Projekt werden Anforderungen in der Reihenfolge des maximalen Business Values umgesetzt. Wurden diese konsequent priorisiert, sind in der Version 1.0 auch die Anforderungen an die IT-Sicherheit der Lösung umgesetzt.
Agile Transformation erforderlich
Eine weitere wichtige Erkenntnis für Banken im Umdenkprozess war, dass sie nicht einfach den Schalter von Wasserfall auf agil umlegen können. Das funktioniert definitiv nicht. Immer wieder scheitern agile Projekte, weil die Anforderungen an eine neue Art des Zusammenarbeitens unterschätzt wurden. Lagen früher bestimmte Arbeitsergebnisse in der Verantwortung der jeweiligen Linienfunktion, also Fachbereich oder IT, so sind in einem agilen Team die Fach- und die IT-Seite gemeinsam für alle Arbeitsergebnisse verantwortlich. Das liegt in der Regel nicht an den Teams und seinen Mitgliedern. Es gibt zwar häufig anfangs ein sogenanntes "Fingerpointing" nach dem Motto: "Dafür bin ich nicht verantwortlich". So eine Reaktion ist aber normal und stammt aus den Erfahrungen aus Projekten mit klar abgegrenzten Bereichen. Haben sich die Teams gefunden, entsteht recht schnell ein Verständnis dafür, dass alle gemeinsam verantwortlich sind, und eigenverantwortlich bestimmen, wie sie das verabredete Ergebnis erreichen.
Das größere Risiko, dass agile Projekte scheitern, besteht darin, dass das Management für agile Projekte nicht die notwendigen Randbedingungen schafft. Zudem machen Unternehmen bei Scrum immer wieder den Fehler, dass die Rolle des Product Owners falsch besetzt oder positioniert wird. Dabei kommt es oftmals zu Kompetenzstreitigkeiten zwischen Product Owner und dem Linienmanagement, welche die Vorteile agiler Methoden konterkarieren.
Ähnlich wie bei der digitalen, braucht es somit immer auch eine agile Transformation. Essenziell ist, die Rolle des Product Owners so stark wie möglich zu machen. Er sollte Fach- und IT-Kompetenz besitzen und somit beide Sprachen sprechen. Der Scrum Master ist eher in der Rolle des Methodenwächters, die Entscheidung, was in welchem Umfang umgesetzt wird, obliegt allein dem Product Owner.
Es braucht Zeit und Übung, um das neue Rollenverständnis zu etablieren. Insbesondere für Bankmanager mit jahrzehntelanger Berufserfahrung ist es manchmal schwer, agile Vorgehensweisen voll anzunehmen. Banken sollten nicht zu viel auf einmal wollen. Sie sind gefordert, diese Führungskräfte abzuholen, durch Best Practices zu überzeugen, sich über kleine, überschaubare agile Projekte heranzutasten und ein gutes Change Management einzuplanen. Eine Wertpapierbank hat sich zum Beispiel ein spezielles Pilotprojekt für die Scrum-Einführung herausgesucht, um wichtige Erkenntnisse zu sammeln. Eine war, dass agile Methoden später nicht für mehr Tickets im IT-Support sorgen. Eine zweite war eine verkürzte Laufzeit des Projekts.
Umstieg bedeutet kulturellen Wandel
Für die erkannten Vorteile investieren Banken mehr in Agilität. Sie läuten mit der Einführung agiler Methoden einen kulturellen Wandel in relevanten Teilen des Unternehmens ein. Vielfach ist das Bild im Umlauf, dass ein Rennboot auf einen Supertanker trifft. Den Lern- und Veränderungsprozess sollten Banken in der Tat nicht unterschätzen. Die Institute haben oft hierarchische Strukturen in der Linie, agile Methoden verlangen aber sich selbst organisierende Teams ohne klassische Führungskraft. Um agile Ansätze mit traditionell starr organisierten Banken zu synchronisieren, braucht es Zeit und ein gezieltes Change Management. Eine Bank setzte zum Beispiel beim Ablösen ihrer Kernbanksoftware durch eine moderne Architektur auf ein zentrales Veränderungsteam zur Einführung agiler Methoden im Projekt. Das besteht aus Mitgliedern der IT und der Fachbereiche. Ein externer Coach begleitete das Team. Dieses Change-Team wählte ein Pilotteam und weitere interessierte Teams aus, ermittelte den Schulungs- und Coachingbedarf und legte Maßnahmen fest.
Die Studie zeigt, dass viele Institute diesen Kulturschwenk noch vor sich haben, oder sie befinden sich mittendrin: 37 Prozent der befragten Entscheider schätzen ihre Projektteams als Scrum-Experten ein, 49 Prozent haben die erste Qualifizierungsoffensive hinter sich. Lediglich elf Prozent stehen gerade am Anfang, ihre Entwickler in agilen Methoden zu schulen.
Viele Widerstände abgebaut
Um diesen Kulturschwenk zu schaffen, müssen Banken Konflikte und vermeintliche Nachteile agiler Methoden überwinden.
- Vielen gestandenen Bankmanagern fehlt beispielsweise der detaillierte Projektplan. Agilität bedeutet aber, dass Bankmanager zukünftig weniger kontrollieren und ihre Mitarbeiter mehr coachen müssen. Über die erstellten Inhalte werden sie vom Product Owner am Ende eines Sprints informiert und ihr Feedback aufgenommen.
- Ein anderer oft erhobener Einwand von Verantwortlichen in den Banken ist die mangelnde Dokumentation im agilen Projektmanagement. Die Dokumentationsanforderungen einer Bank und die agile Vorgehensweise sind aber kein Widerspruch. Anforderungen an ein auszulieferndes Stück Software werden im Scrum beispielsweise in der Definition of Done festgelegt und entsprechend nachgehalten. Auch die Dokumentation der Software ist eine derartige Anforderung und muss in die agile Projektplanung einbezogen werden. Der Umfang der Dokumentation orientiert sich dabei streng am Nutzen.
- Ein dritter Kritikpunkt ist, dass agiles Vorgehen keine bankenkonformen Abnahmetests erlauben. Aufgrund bankinterner Vorgaben ist ein Rollout in Produktion normalerweise erst nach einem umfänglichen Nutzertest möglich. Grundidee dabei ist, dass die IT-Abteilung ein Stück Software nach Spezifikation entwickelt und erst nach erfolgreichem IT-Test die komplette Anwendung dem Fachbereich beziehungsweise Auftraggeber zum Test zur Verfügung stellt. Dieses Prozedere ist konträr zur agilen Idee. Da am Ende eines jeden Sprints ein potenziell releasefähiges Stück Software erstellt wird, muss dieses auch von dem agilen Team getestet werden. Regelmäßige Anpassungen und Erweiterungen an bereits bestehenden Projektergebnissen führen dazu, dass die Tests idealerweise automatisiert oder teilautomatisiert sind. Diese Tests sind in der Definition of Done festzuhalten und einzuplanen.
Nicht immer das Allheilmittel
Zusammenfassend wird deutlich, dass es wichtig ist, nicht blind auf den agilen Zug aufzuspringen. Entscheidend ist, dass ein Einsatz agiler Methoden sinnvoll ist. Agil ist kein Selbstzweck, sondern muss zielgerichtet ein gesetzt werden. Dies können Banken inzwischen mehrheitlich feststellen: Zwei von drei für die Studie befragten Instituten vermelden messbare Produktivitätssteigerung und Kosteneinsparungen durch den Einsatz agiler Vorgehensweisen. Fast genauso viele (63 Prozent) verzeichnen kürzere Laufzeiten.
*) Die Studie "Agile Methoden in Banken und Versicherungen" der PPI AG (https://www.ppi.de/software-entwicklung/vorgehen/studie-agile-methoden) untersucht, wie häufig und mit welchem Erfolg Banken und Versicherungen agile Methoden in IT-Entwicklungsprojekten einsetzen. Dazu befragte das IMR Institute for Marketing Research GmbH im Februar 2016 IT-Experten und -Entscheider aus 35 Kreditinstituten und 30 Versicherungen. Die Teilnehmer wurden telefonisch im Rahmen einer CATI-Befragung (Computer Assisted Telephone Interview) befragt.
