L-Bank

Wie sich eine Bank mit agilen Methoden wandelt

13.11.2014
Axel Bayer ist Direktor des Bereichs IT bei der L-Bank in Karlsruhe.
Mit der breiten Einführung von Agilität ändert sich mehr als nur das Rahmenwerk für Softwareprojekte, sie läutet vielmehr einen Kulturwandel ein. Trotzdem - oder gerade deswegen - lohnt es sich, auch in einem Unternehmen mit traditionell gewachsenen Strukturen Agilität zu etablieren.

Vor zwei Jahren entschied sich die L-Bank, Staatsbank für Baden-Württemberg, ihre IT-Landschaft zu harmonisieren und zu erneuern. Das war der Auslöser für das Programm zur Transformation mittels agiler Methoden. Aber was löste das Bedürfnis für die Harmonisierung aus?

Die L-Bank - hier die Zentrale in Stuttgart - hat ihre IT-Landschaft mittels agiler Methoden transformiert.
Die L-Bank - hier die Zentrale in Stuttgart - hat ihre IT-Landschaft mittels agiler Methoden transformiert.
Foto: photo@davidfranck.de 2009

Dafür gab es unterschiedliche Gründe. Zunächst waren die bestehenden IT-Anwendungen zu einem großen Teil teuer in der Wartung und im Unterhalt. Zudem ist das zur Wartung benötigte Know-how immer seltener verfügbar - weder intern noch extern. Gleiches galt für die Techniken: Teilweise basieren die betagten Systeme auf veralteten, nicht mehr weiterentwickelten Programmiersprachen.

Wartungsaufwand und mangelnde Flexibilität - das waren die beiden Faktoren, die Änderungsbedarf schufen. Die "Trägheit" der monolithischen Altsysteme steht in deutlichem Gegensatz zu dem konstanten Anpassungsbedarf, wie er sich zum Beispiel aus der Regulatorik ergibt. Oder anders herum ausgedrückt: Die Bank brauchte eine flexible Architektur mit wenigen Abhängigkeiten und möglichst geringen Anzahl an festen Schnittstellen.

Das größte Projekt in diesem Zusammenhang war die Erneuerung der Kernbankensoftware, besonders des Nebenbuchsystems. Dort werden die Förderdarlehen geführt, also das Kerngeschäft der Bank. Zu diesem Projekt gehört auch die Anpassung beziehungsweise Erneuerung der Systeme zur Antrags- und Bestandsbearbeitung für dieses Geschäft.

Grundsatzfragen

Im Verlauf des Projekts wurde bald erkennbar, dass bestimmte Ansätze nicht zielführend waren. In der Konsequenz hieß das: Weg vom ursprünglichen Standardansatz, hin zu einer Mischform aus Eigenentwicklung und Standardsoftware. Das versprach einerseits die notwendige Flexibilität und Individualität, andererseits aber auch die Nutzung von Skaleneffekten.

Doch damit musste der gesamte Bebauungsplan neu überdacht werden, besonders im Bereich der Sachbearbeitungsprozesse. Diese inhaltliche Zäsur im Bebauungsplan nutzte das Team, um nochmals innezuhalten und eine weitere Grundsatzfrage zu stellen: War die klassische Projektmethodik eigentlich zielführend?

Aus Sicht des Managements musste diese Frage verneint werden. Qualität und Fertigstellungsgrad waren nicht transparent genug. Außerdem gab es nur begrenzt Steuerungsmöglichkeiten. Und auch die Projektmitarbeiter wünschten sich mehr Transparenz und weniger Verwaltungs-Overhead.

Schon in der Vergangenheit hatte die IT der L-Bank ein Großprojekt mit agilen Prinzipien gemeistert: Die Einführung des Elterngelds. Damit drängten sich agile Ansätze als Antworten auf die aktuellen Herausforderungen geradezu auf.

Geteilte Verantwortung

Allerdings bringen solche Ansätze ihre eigenen Herausforderungen mit. Beispielsweise verändern sie die organisatorischen Strukturen: Banken haben normalerweise hierarchische Strukturen in der Linie, agile Methoden verlangen dagegen sich selbst organisierende Teams ohne klassische Führungskraft.

Sachlich betrachtet, bestand die größte Änderung darin, den Fachbereich in die inhaltliche Verantwortung zu bringen, während sich die IT auf technische Aspekte und Umsetzungsthemen fokussiert. Das bedeutet, Zuständigkeiten ganz neu zu klären. Insgesamt wurde damit ein kultureller Wandel eingeläutet, der konstant im Fluss ist.

Zunächst bildete die Bank ein zentrales Veränderungsteam, das sich aus Mitgliedern der IT und der Fachbereiche zusammensetzte und von einem externen Coach begleitet wurde. Dieses Change-Team wählte sich für das erste halbe Jahr ein Pilotteam aus, um dann weitere interessierte Teams in den Fokus zu nehmen. Außerdem hat es Schulungs- und Coaching-Bedarf evaluiert und anstehende Maßnahmen festgelegt.

Just-in-time-Planung statt Feinkonzept

Die Fachbereiche reagierten positiv auf die Veränderungen durch eine engere Verzahnung zwischen ihnen und der IT. Zu diesen Veränderungen zählt beispielsweise eine Just-in-time Planung statt des gewohnten Feinkonzepts. Bis dahin waren die Konzepte immer sehr technisch und mussten von Systemexperten erstellt werden. Nun konnten Sachbearbeiter und Fachbereichsverantwortliche zum ersten Mal selbst und direkt Anforderungen stellen sowie priorisieren.

Das führte allerdings teilweise dazu, dass die Auswirkungen für nachgelagerte Stellen, an denen die Daten zum Beispiel für Auswertungen weiterverarbeitet werden sollten, nicht immer hinreichend berücksichtigt wurden. Am Anfang sahen die Sachbearbeiter eben vor allem die Anforderungen, die sie selbst betreffen.

Rollen definieren und sinnvoll besetzen

Um Product Owner und Tester auf ihre Aufgaben vorzubereiten, stimmte sich die IT mit den Linienvorgesetzten aus den Fachbereichen ab: Es galt, die Anforderungen an die Rollen gemeinsam zu definierenn, dann die geeigneten Personen für die Rollen von Product Owner und Tester auszuwählen, ihnen die nötigen Kompetenzen zu übertragen und sie intensiv zu schulen sowie zu coachen.

Bei der Skalierung und der Frage, wer als Chief Product Owner in Frage kommen könnte, stand die Verantwortung im Fokus, die diese Rolle haben sollte. Intensiv diskutiert wurde auch, aus welchem Bereich die betreffende Person kommen sollte. Schließlich einigten sich alle beteiligten Bereichsleiter auf einen Chief Product Owner aus dem Organisationsbereich und sagten ihm ausdrücklich ihre Unterstützung zu.

Integrierte Fachbereiche

Wegen der geteilten Verantwortung (Fachbereich inhaltlich, IT technisch) sollten Mitarbeiter aus dem Fachbereich direkt in die agilen Teams eingebunden werden. Dabei war es wichtig, dass der inhaltliche Kontakt zum Fachbereich nicht verloren ging, also der Austausch mit den Fachkollegen aufrechterhalten blieb. Deshalb wurden die Fachbereichsmitarbeiter anfangs nur zu einem Teil ihrer Arbeitszeit dem Projekt und den Scrum-Teams zur Verfügung gestellt.

Aber schnell wurde klar, dass im Interesse des Projekterfolgs eine Vollzeitmitarbeit der Fachbereichskollegen notwendig war. Um auf dem Laufenden zu bleiben, wurden die eingespielten Kommunikationswege genutzt: gemeinsame Mittagessen, Abteilungs- und Bereichsversammlungen etc. Das ist ein Punkt, der umso mehr beobachtet werden muss, je länger ein Projekt dauert.

Teil der Verantwortung übergeben

Die IT verlor zunächst partiell an inhaltlicher Eigenständigkeit. Aber sie zog auch Vorteile aus der neuen Vorgehensweise. Tatsächlich schätzte sie von Anfang an die intensive Zusammenarbeit mit dem Fachbereich. Denn auf diese Weise bekommt sie die Anforderungen früher, besser und klarer priorisiert. Zudem sind die Abnahmetests direkt in den Entwicklungsprozess integriert. Kurz: Der Fachbereich übernimmt einen Teil der Verantwortung.

Damit Teams aus Fachbereichsmitarbeitern und Entwicklern zusammenfinden, ist es von großem Vorteil, dass sie in direkter räumlicher Nähe sitzen. Das fördert eine enge Zusammenarbeit und kurze Wege. Die notwendigen Ansprechpartner sind direkt verfügbar, wenn Fragen auftauchen oder Abstimmungen nötig sind.

Darüber hinaus gibt es informelle Teambildungsmaßnahmen, beispielsweise gemeinsames Kochen unter der Anleitung eines professionellen Kochs. Es mag trivial klingen, aber beim kollektiven Schnippeln und Rühren entstehen zwangslose Kontakte, die sich später auf den beruflichen Kontext positiv auswirken.

Grundskepsis

Selbstverständlich sind die Ansichten zur neuen Vorgehensweise im Team unterschiedlich. Auf jeden Fall gibt es einige Dinge, die niemand mehr missen will, etwa die enge Verzahnung zwischen Fachbereich und IT. Dennoch müssen viele Betroffene erst in die Rollen hineinwachsen, die solch ein Kulturwandel mit sich bringt. Eine gewisse Grundskepsis ist da natürlich, und die wird sich erst im Laufe der Zeit ganz legen.

Auch für die IT der L-Bank ist die agile Transition neu. Und wenn man etwas Neues macht, ist es sinnvoll, einen Experten zu konsultieren. Deshalb wurde ein "Agile Coach" von der andrena objects ag, Karlsruhe engagiert. Er sollte die Mitarbeiterinnen und Mitarbeiter in den "agilen Rollen", beispielsweise Product Owner und Scrum Master, coachen sowieden Veränderungsprozess begleiten und Sorgfalt darauf verwenden, dass die agilen Prinzipien eingehalten werden. andrena stellte auch zusätzliche Entwicklungskapazität bereit.

Auf keinen Fall sollte das Etikett "Agilität" auf etwas geklebt werden, das in Wirklichkeit etwas Anderes wäre. Externe Experten direkt in ein Scrum-Team zu holen bedeutet auch, unmittelbar neue Impulse zu erhalten - vor allem im Hinblick darauf, wie sich die Agilität in die Praxis überführen lässt.

Lessons learned

Das Programm ist noch lange nicht fertig. Doch es wurde bereits Einiges erreicht. Es war möglich, mit einigen iterativ erstellten Teilstücken produktiv zu gehen, obwohl sich die Einflussgrößen während des Vorhabens veränderten. Die Ergebnisse waren bereits den neuen Anforderungen angepasst. Das hätte sich bei der vorherigen Entwicklungsgeschwindigkeit sicher nicht machen lassen.

Zu den wichtigsten Erkenntnissen, die sich aus dem Vorhaben ziehen ließen, gehört vor allem eines: Ein Change-Team, das den Prozess steuert, ist unabdingbar. Möglicherweise wäre es hilfreich gewesen, mehr Vorarbeit zu leisten und noch deutlicher das "Wieso und Weshalb" herauszuarbeiten sowie zu kommunizieren.

Transition bedeutet Kulturwandel, und dementsprechend sollte der Kommunikationsprozess ausgerichtet werden. Man sollte sich darüber im Klaren sein, dass Wandel harte Arbeit ist, die einem letztendlich niemand abnehmen kann. Man kann sich nicht darauf verlassen, dass ein einmal angestoßener Prozess von allein läuft.

Der Wechsel auf eine agile Vorgehensweise ist nicht im klassischen Sinn ein Projekt, sondern ein Weg, den man einschlägt. Nach anderthalb Jahren kann man wohl sicher sein, den richtigen Pfad gewählt zu haben. Deshalb wird die L-Bank weiterhin auf ihre agilen Ziele hinarbeiten. (qua)

Daten und Fakten zur L-Bank

Die L-Bank ist die Staatsbank für Baden-Württemberg. Als Förderbank des Landes unterstützt sie Wirtschaft, Kommunen und Menschen im Bundesland.

Sie hatte 2013 eine Bilanzsumme von fast 71 Milliarden Euro vorzuweisen und beschäftigt mehr als 1.250 Mitarbeiter am Hauptsitz in Karlsruhe und der Niederlassung in Stuttgart.

Kleine und mittlere Unternehmen fördert sie bei Neugründungen, Übernahmen, Investitionsvorhaben und Energiesparmaßnahmen. Sie hilft Kommunen beim Ausbau ihrer Infrastruktur sowie Bauherren und Käufer auf ihrem Weg zum eigenen Haus oder zur Eigentumswohnung.

Zudem vergibt die L-Bank Fördermittel für den Bau von sozialem Mietwohnraum, Elterngeld, Betreuungsgeld sowie Erziehungsgeld, und sie finanziert Bildungsmaßnahmen.

Projektsteckbrief

  • Branche: Förderbank (Anstalt des öffentlichen Rechts)

  • Projektkategorie: Transition der Vorgehensweise - von Wasserfall zu agil

  • Herausforderungen: Kulturwandel in IT und Fachbereichen

  • Ergebnis: Flexiblere Prozesse, besseres Alignment

  • Stand des Projekts/Zeitrahmen: Anfang 2013 begonnen, noch in Arbeit, Ongoing Process

  • Involvierte Anbieter/Dienstleister: andrena objects ag, Karlsruhe

  • Ansprechpartner: Axel Bayer, L-Bank