Agile Transformation in Banken- oder die wahre Geschichte der agilen Frustration?! Und was ist Bananensoftware? #agile

Schnelles Time-to-Market, Flexibilität bei Anforderungen und selbstentscheidende Teams sind hier schlagende Argumente. Es gibt kaum eine Bank, die agile Methoden heutzutage nicht einsetzt.
Es basiert auf den agilen Grundprinzipien:
•    Inspektion
•    Adaption
•    Transparenz

Klingt doch alles sehr verlockend, oder etwa nicht?!

Warum begegne ich in den Banken dennoch so vielen frustrierten Menschen? Da gibt es Mitarbeiter, die am liebsten „die alten Zeiten“ wieder her wünschen, ein Management, das kaum mehr ansprechbar ist, da es zwischen verschiedenen Teams die Fäden zusammenzuhalten versucht und Kunden , die sich über wachsende Probleme mit der Software beschweren und diese als Bananensoftware (Software, die beim Kunden reift) bezeichnen.

Agile Frustration
Ich habe mich gefragt, was diese agile Frustration bei den Menschen auslöst. Liegt es an dem Framework selber, wird es falsch eingeführt oder stehen die strengen regulatorischen Anforderungen an Banken hier im Widerspruch? Wie so häufig ist nicht immer nur ein Faktor ausschlaggebend, sondern mehrere.

Agile Software(bananen)entwicklung…
Leider ein häufiger Grund, warum eine agile Softwareentwicklung für die Bank nicht sinnvoll eingesetzt wird. In dem folgenden Fall hatte sich die Bank löblicherweise eine agile Softwareentwicklung auf die Fahne geschrieben. Es wurden die Scrum-Rollen Mitarbeitern zugewiesen und die Scrum-Events und Artefakte eingeführt. Allerdings arbeitete man bei genauer Betrachtung in einem „agilen Wasserfall“, d. h. mehrere Sprints Konzeption, dann Umsetzung, dann Test, dann Release.

und agile Frameworks oder sowas in der Art…
Meine erste Vermutung war, dass man das agile Framework nicht verstanden hatte, aber die Ursachen waren andere. In erster Linie hat das Institut den Grundgedanken einer agilen Softwareentwicklung nicht verstanden bzw. umgesetzt. Nehmen wir mal das Beispiel Vertrieb. Dieser machte in der Diskussion von Zwischenergebnissen mit dem Product Owner klar, dass seinen Kunden maximal einmal pro Jahr funktionale Änderungen zuzumuten wären und er das volle Funktionspaket benötigte.
 

und zu späte Reviews
Dementsprechend tauchte er dann auch erst zum letzten Review-Termin vor dem Release auf, um seine Anmerkungen zu geben. Die Konsequenz war, dass ca. ein halbes Jahr an Softwareentwicklung zurückgebaut werden musste, weil erst zu einem viel zu späten Zeitpunkt festgestellt wurde, dass die vehement eingeforderte und hoch priorisierte Funktionalität nicht sinnvoll und viel zu komplex für den Kunden ist.
 

Verpasste Inspektionen und zu spät erstellte Anforderungen
Hier wird ein wesentlicher Punkt der agilen Softwareentwicklung vernachlässigt, nämlich der Punkt Inspektion. Rückmeldung kommt immer erst kurz vor dem Release, was dazu führt, dass neue Anforderungen erst nach dem release-bedingten Code Freeze gestellt und dann hektisch nachentwickelt wurden. Hier hat das agile Framework nur die Legitimation geliefert, Anforderungen sehr spät zu stellen, um beim gewohnten Verhalten bleiben zu können. In diesem Fall führte das zu wachsender Frustration bei den Entwicklern, da sie nun keine Argumente mehr hatten, späte Anforderungen abzuweisen. Aber auch die Kundenseite sah keinen Mehrwert - es wurde ja gearbeitet wie immer.

Kardinalsfehler und nicht angepasste IT-Prozesse
Erschwerend wurden auch die IT-Prozesse nicht angepasst, die immer von festen Releasezyklen ausgehen und eine agile Entwicklung nicht unterstützen, da man z. B. feste Quality Gates für Fachkonzepte und andere klassische Ergebnistypen einfordert. In der Konsequenz musste man im „agilen Wasserfall“ entwickeln. Der Kardinalsfehler bei der Einführung von Scrum war, dass das Unternehmen im Ganzen nicht auf die agile Reise mitgenommen wurde.

Ist das nun „Agile Transformation“ oder nur `ne PR-Nummer?
Agile Entwicklung war nur Teil der IT-Entwicklung. Es wurden weder Stakeholdern – wie dem Vertrieb – das neue Mindset und die geänderte Arbeitsweise vermittelt, noch wurden die bestehenden IT-Prozesse einer agilen Entwicklung angepasst. Agile Entwicklung diente ausschließlich der Legitimation später Anforderungen aufgrund später Feedbacks und als Marketingaussage, dass man moderne Softwareentwicklung könne. 


Mein Fazit: „agilifizieren“
In diesem Fall wäre es besser gewesen, inkrementell Iterativ zu arbeiten und vielleicht erst in der Folge pilothaft auf agile Softwareentwicklung umzustellen. Nicht immer wird der Einsatz des agilen Frameworks ein Unternehmen weiter bringen. Wichtig ist es, zu verstehen, ob ich damit meinen Kunden einen Mehrwert bieten kann, oder ob diese, da z. B. sehr konservativ geprägt, sogar verschreckt werden. Sehr wichtig ist es auch, die IT-Prozesse zu „agilifizieren“. Ist man überzeugt, den agilen Weg gehen zu wollen, muss das komplette Institut auf diese Reise mitgenommen werden. Aber dazu mehr in meinem nächsten Blogbeitrag.


Beste Grüße
Andreas Milanese

PS: Wer nicht abwarten kann oder an einer Beratung interessiert ist, darf auch gerne meine Website besuchen unter: http://www.ppi.de/banken/compliance/agiles-projektmanagement/

Reaktionen:

0 Kommentare:

Kommentar posten