Anwendung von agilen Entwicklungsmethoden im Data-Warehouse-Umfeld in der Finanzindustrie

Agilität in der Bankensteuerung?

In den letzten zwei Jahrzehnten haben agile Entwicklungsmethoden stark an Popularität gewonnen. Dieser Trend ist auch an Banken und anderen finanziellen Institutionen nicht vorbei gegangen. Scrum, Kanban und andere Methoden werden hier eingesetzt, um neue Level der Produktivität sowie eine bessere Performance im Hinblick Zeit, Kosten und Qualität in IT-Projekten zu erreichen.

Einer der initialen Impulse für Banken, sich mit den agilen Methoden zu befassen, ist der zunehmende Druck zu schnellen, flexiblen Anpassungen von Systemen zur Erfüllung neuer, auch regulatorischer Anforderungen. Aufsichtsbehörden drängen auf schnelle Meldelösungen und qualitative Verbesserungen, welche in zeitlich engem Rahmen und unter Kostendruck implementiert werden müssen. Viele dieser Lösungen erfordern Veränderungen oder Erweiterungen der vorhandenen dispositiven Systeme. Gerade die Entwicklungsmethoden von Data-Warehouses (DWHs), welche als zentrale Informationshubs der Steuerungsdisziplinen der Banken dienen, sind deshalb häufig das Ziel von Veränderungen und Erweiterungen.

In diesem Umfeld folgt die Entwicklung typischerweise dem sequenziellen Wasserfallansatz/V-Modell mit langen Entwicklungszyklen, sodass häufig provisorische Workarounds für mehr Flexibilität geschaffen werden – zulasten einer nachhaltigen, dauerhaft betreibbaren Lösung, da diese Workarounds häufig nicht zurückgebaut werden und daher mittel- bis langfristig bestehen bleiben. Wenn dann irgendwann die Komplexität zu groß wird, führt dieses Vorgehen typischerweise zu hohen Investitionen zur Schaffung neuer, nachhaltiger Lösungen; bis dahin ist mit erhöhten Kosten beim Betrieb der Systeme zu rechnen.

Agile Entwicklungsmethoden sind dagegen auf schnelle Lieferung durch hohe Interaktivität zwischen fachlichen Anforderern sowie technischen Umsetzern ausgelegt und eignen sich daher sehr gut für Projekte, in denen die Anforderungspräzisierung und Entwicklung Hand in Hand verlaufen müssen, um die zeitlichen Restriktionen einzuhalten und einen hohen Grad an Flexibilität bis kurz vor Fertigstellung zu erreichen. Im Gegensatz zur sequenziellen Wasserfallentwicklung bieten agile Methoden den Baukasten für schnelle und flexible Entwicklungszyklen durch gemeinschaftliche Anstrengungen von sich selbst organisierenden funktionsübergreifenden Teams und aktive Einbeziehung der Endbenutzer. Ganz ohne Gefahren ist das nicht: Unbedarfte Anwendung ohne entsprechenden Aufbau der Organisation und der Prozesse führt gerade in der Anfangsphase oftmals zu drastischen Produktivitätseinbrüchen, die häufig als Anlass genommen werden, die agilen Entwicklungsmethoden zumindest teilweise wieder zu verwerfen. Darüber hinaus sind aufgrund der komplexen, stark abhängigen Prozesse in der Unternehmenssteuerung Besonderheiten gegeben, die bei der Etablierung agiler Entwicklungsmethoden im DWH-Umfeld besonders zu beachten sind.

Gerade im Umfeld von DWHs kommt es häufig zu Priorisierungen der Anforderungen aus verschiedenen Fachbereichen. Für diese Anforderungen muss initial die Priorität innerhalb der Bank festgestellt werden, bevor anschließend die Planung, Entwicklung und Inbetriebnahme erfolgen können. Gerade wenn die Änderungen sehr groß sind, besteht die Gefahr, dass diese nicht wie ursprünglich geplant fertiggestellt und die benötigten Ressourcen wieder frei gegeben werden. Hier bieten agile Entwicklungsmethoden die Chance, eine höhere Flexibilität in der Steuerung der Entwicklung zu schaffen und trotzdem die Stabilität des Systems zu erhalten.

Agile Methodik

Der agile Ansatz für die Entwicklung von Software kann in die folgenden vier Statements (agiles Manifest) zusammengefasst werden, welches von den 17 Begründern der Agile Alliance im Februar 2001 formuliert wurde:

Abbildung 1: Agiles Manifest

Die Autoren des agilen Manifests untergliedern dieses weiter in zwölf Prinzipien. Innerhalb dieser fordern sie dazu auf, (Software-)Entwicklungsprojekte um motivierte Individuen zu konzipieren und funktionierende Software (oder ein entsprechendes Endprodukt) als das finale Ziel anzusehen. Die zwölf  Prinzipien fordern und fördern die effektive Zusammenarbeit innerhalb und zwischen Teams mit dem Ziel, einen schnelleren und flexibleren  Entwicklungsprozess zu erschaffen, welcher Veränderungen der initialen Anforderungen zulässt, ohne den Entwicklungsabschluss wesentlich zu stören.

Aber gerade aus Bankensicht ist eine 1:1-Umsetzung des agilen Manifests nicht immer möglich, es muss eine Anpassung an die Anforderungen in der Finanzindustrie erfolgen. Dies gilt beispielsweise für den Schritt „working software over comprehensive documentation“. Im Bankwesen besteht ein hoher Anspruch an die Dokumentation und den Nachweis der Funktionsweise der Software (z. B. gemäß den Grundsätzen aus BCBS #239). Bei der Softwareentwicklung muss eine umfassende und korrekte Dokumentation angefertigt werden, bevor eine Software produktiv gesetzt werden darf; die Dokumentation ist integraler Bestandteil der Abnahme. Auch andere Werte sind zu prüfen: In manchen Fällen fordert die Aufsicht konkrete Umsetzungspläne an (z. B. bei der Abarbeitung von aufsichtsrechtlichen Feststellungen oder vereinbarte Meilensteine für regulatorische Umsetzungen), deren Nichtbefolgung mit negativen Folgen wie Kapitalaufschlägen geahndet werden kann.

Herausforderungen beim Übergang zum Einsatz von agilen Entwicklungsmethoden im DWH-Umfeld

Die Transformation von klassischen zu agilen Entwicklungsmethoden hat zum Ziel, die Flexibilität bei gleichzeitiger Gewährleistung der Stabilität erhöhen. Generell muss bei der Einführung von agilen Methoden eine Vielzahl von Aktivitäten und Einschränkungen beachtet werden – ein naives „Reinstolpern“ in agile Methoden ist meist mit negativen Konsequenzen verbunden.

Besonders zu beachten sind hier insbesondere der notwendige kulturelle Wandel, um die Beharrungskräfte aufzulösen und Ängste zu nehmen, die Wissensvermittlung bezüglich der neuen Konzepte und Methoden, um die Fertigkeiten als Grundlage für das veränderte Vorgehen zu schaffen, sowie die Anpassung der Rollen, Verantwortungsbereiche und Prozesse. In all diesen Bereichen kann typischerweise eine große Anzahl von Hindernissen und Komplikationen beobachtet werden.

In vielen Fällen sind Fehlinterpretationen des agilen Ansatzes die Ursache dafür, dass die erhofften Vorteile nicht oder nicht so schnell erzielt werden können. Typische Muster sind beispielsweise:

1. „Halb-Agilität“ – In vielen Fällen verfahren Banken nach dem „Pick and Choose“-Ansatz bei der Einführung von agilem Arbeiten. Dies wird häufig mit dem Motiv gemacht, „die Kontrolle zu behalten“, in manchen Fällen aber auch wegen des fehlenden Verständnisses für die agile Methoden insgesamt und des fehlenden Überblicks, was das Weglassen von Komponenten der agilen Methodik an Konsequenzen nach sich zieht.
2. Unsauberer Übergang zwischen agilen und „nicht agilen“ Projekten – In manchen Fällen führen Banken die agile Entwicklung für kleine, kurzzeitige Projekte ein, welche in einem sonst gemäß dem Wasserfall strukturierten Entwicklungsumfeld agieren. Fehlende Handover-Prozesse führen in diesem Szenario zu unklaren Verantwortungsbereichen und Methodenbrüchen, insbesondere im Test.
3. Verzicht auf Planung – Agilität wird als Ausrede genommen, um nicht mehr planen zu müssen. Dies führt u. a. zu permanenter Priorisierung von zeitkritischen Arbeitspaketen nach dem „(Sprint) Commitment“ führt, worunter meist sowohl Qualität der Entwicklung als auch deren Dokumentation leiden. Gerade im regulatorischen Umfeld mit harten Deadlines ist dieses kurzsichtige Vorgehen nicht vertretbar.
4. Vernachlässigung der Dokumentation – Agile Methoden werden auch mit der Erstellung von Dokumentation „im Vorbeigehen“ sowie ohne definierte und angemessene Qualitätssicherung oder Statusabschluss verwechselt. Dies geschieht häufig durch sich ändernde Anforderungen, Formulierung von Anforderungen post factum (also nachdem die Entwicklung stattgefunden hat) oder fehlendes Verständnis für die Besonderheiten von Banken, die gerade im regulatorischen Umfeld hohen Dokumentationsanforderungen unterliegen.
5. Unzureichende Teambesetzung – Eine der größten Herausforderungen der agilen Entwicklung ist die Sicherstellung von funktionsübergreifenden Teams, die intern alle benötigten Fähigkeiten besitzen, um die gestellte Herausforderung abarbeiten zu können. Gerade konkurrierende Abhängigkeiten zu anderen Teilen der Organisation werden häufig nicht hinreichend aufgelöst. Hinzu kommt, dass die Teammitglieder durch ineffektives Ressourcenmanagement oder auch „traditionelle“ Aufgabenverteilungen unterschiedlich ausgelastet werden.
6. Unzureichende Synchronisation zwischen den agilen Teams – Im Verhältnis zur kleinteiligen Softwareentwicklung an gut abgrenzbaren und stark entkoppelten Softwareelementen wird beim agilen Arbeiten am DWH eine sehr enge Zusammenarbeit und ein deutlicher, permanenter Informationsaustausch zwischen den unterschiedlichen Scrum-Teams erforderlich, um überlappenden Tätigkeiten und End-to-End-Effekten angemessen zu berücksichtigen.
7. Ungenügendes Testen – Gerade die enge Kooperation von funktionsübergreifenden Teams führt häufig zur Akzeptanz von niedrigen Teststandards mit der Begründung, dass „der Fachbereich aktiv im Entwicklungsprozess beteilig war.“ In der Folge werden längere Stabilisierungsphasen benötigt, die für die kurzen Testphasen kompensieren. Dadurch werden Folge-Sprints mit Stabilisierungsthemen geblockt und der Weiterentwicklung entzogen. Es wird quasi im Produktivbetrieb getestet.
8. Fehlende Nachhaltigkeit – Die Ambition, kürzere Releasezyklen zu realisieren, geht häufig auf Kosten der Verständlichkeit, der nachhaltigen Realisierung (Wartbarkeit, Weiterentwickelbarkeit) und der Qualität der Dokumentation. Dieses wiederum beeinträchtigt die Haltbarkeit des Gesamtsystems längerfristig und führt zu einem „Technical Debt“, einem Kredit auf die Zukunft zugunsten aktueller Entlastungen.

Erfolgsfaktoren für einen möglichst reibungslosen Übergang zum agilen Arbeiten

Für sich alleine genommen sind die Konzepte der agilen Entwicklung und speziell des häufig anzutreffenden Scrum-Ansatzes verhältnismäßig einfach und verständlich. Eine erfolgreiche und unternehmensweite Einführung des agilen Ansatzes erfordert jedoch ein strukturiertes Vorgehen und einen umfassenden Transformationsplan, um den Erfolg sicherzustellen. Ein solcher Plan muss ein konsistentes Vorgehensmodell der agilen Entwicklung unter Berücksichtigung der Besonderheiten der Anforderungen und der Voraussetzungen der Bank sicherstellen, um Antworten auf die im vorigen Absatz gelisteten Herausforderungen zu liefern. Insbesondere müssen die Bereiche Governance und Organisation, Menschen und Training sowie Tools und Technologie abgedeckt werden.

Abbildung 2: Erfolgsfaktoren des agilen Ansatzes

Governance und Organisation

Wichtig ist hier, dass sich die Organisation mit allen Beteiligten sowie Prozesse und „Spielregeln“ entlang der agilen Vorgehensweise ausrichten. Eine gute Vorbereitung unter Berücksichtigung aller vorhandenen Restriktionen (z. B. aufsichtsrechtliche Regelungen, systemspezifische Besonderheiten, verfügbare Infrastruktur, parallele Existenz von agilen und nicht agilen Methoden) erhöht die Akzeptanz. Dazu muss auch das Management hinter dem Vorhaben stehen und bei Rückschlägen und Problemstellungen den Willen zur Umstellung besitzen. Dabei hilft auch die wiederholte Kommunikation in Richtung aller Stakeholder, die frühe Realisierung von „Quick Wins“ und die aktive Vermarktung dieser Erfolge.

Menschen und Training

Gerade bei der agilen Entwicklung hängt der Erfolg im besonderen Maße von den Menschen ab – nicht ohne Grund stehen bei drei der vier agilen Statements der Mitarbeiter, die Interaktion und die Flexibilität im Vordergrund. Das Prinzip der autonomen, funktionsübergreifenden, selbst organisierenden Teams stellt besondere Anforderungen an die Qualifikation und Motivation der Mitarbeiter und an die Bereitschaft, reflektiert und bewusst Änderungen anzustoßen und Flexibilität zu ermöglichen. Training und Weiterbildung sind in dieser Umgebung notwendige Maßnahmen. Der kulturelle Wandel, der dafür notwendig ist, ist in vielen Fällen ein beobachtetes Problem und sollte daher von vornherein wesentlicher Bestandteil der Überlegungen bei der Einführung agiler Methoden sein (sieh auch: Deutschland sucht den agile Coach).

Tools und Technologie

Zur Unterstützung der Qualitätssteigerung sollten auch entsprechende Tools ausgewählt und genutzt werden, um die Umsetzung agiler Methoden zu erleichtern. Häufig können vorhandene Tools mit geringen Aufwänden angepasst und parametrisiert werden, um diesen Zwecken zu genügen. Dabei sollte gerade für die regelmäßige Abstimmung im Team auf Visualisierung und einfaches Tracking gesetzt werden, um unnötigen Overhead zu vermeiden. Es ist aber auch wichtig, von Anfang an die Qualitätssicherung soweit möglich mit einem hohen Automatisierungsgrad zu etablieren sowie die Dokumentationsformen festzulegen. Gerade hier können durch die Anfangsinvestitionen größere Folgeaufwände vermieden werden.

Zusammenfassung

Agile Methoden sind schlagkräftige Ansätze, welche bei richtiger Umsetzung den Banken helfen, sich an veränderte Rahmenbedingungen und stetig ansteigende regulatorische Anforderungen anzupassen. Die – meist von außen auferlegten – Flexibilitätsanforderungen stellen die Umsetzungsprojekte im DWH-Umfeld vor große Herausforderungen – technisch, organisatorisch, aber auch kulturell. Die meisten Einführungsansätze stoßen jedoch sowohl initial als auch später auf eine Anzahl von Hindernissen, die durch Nachjustierung und ständige Reflexion aus dem Weg geräumt werden müssen. Dies hat hauptsächlich damit zu tun, dass die agilen Entwicklungsmethoden kein „out of the box“-Ansatz darstellen, sondern eher Leitlinien, die auf die spezifischen Besonderheiten angepasst werden müssen. Das erfordert auch ein grundsätzliches, unternehmensweites Umdenken in den Changeprozessen – von den Anforderungen bis zur Produktivsetzung, über alle Hierarchieebenen und Disziplinen hinweg.