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

Scrum: Just another f** method? Der Agile Change in den Köpfen ist der schwerere

 Ach was habe ich schon alles an unterschiedlichen Methoden kennen lernen dürfen, Wasserfall, V-Modell, Inkrementell iterativ und wie sie nicht alle heißen. Was macht man dann? Natürlich eine Schulung oder schlaue Bücher lesen. Gleiches dachte ich am Anfang auch über Scrum, das wohlgemerkt keine Methode, sondern ein Framework ist. Ich habe mir den Scrum Guide durchgelesen, später dann meine Zertifizierungen zum Scrum Master und Product Owner gemacht, wie so viele andere. Während aber Methoden Ergebnistypen definieren und auch sehr viele Vorlagen hierfür existieren, gibt es so etwas bei Scrum nicht und das ist volle Absicht. Scrum versteht sich, wie oben erwähnt, als ein Framework.

Agile, the new way of thinking.

Das bedeutet, es vermittelt im Wesentlichen eine Idee und einen Rahmen, wie man diese umsetzt. Leider führt das auch dazu, dass Scrum häufig schlecht eingesetzt wird, da die Grundideen nicht erkannt oder umgesetzt werden. Es geht also nicht nur darum, seinen eigenen Werkzeugkoffer zu erweitern, sondern ein Umdenken im bisherigen Handeln herbei zu führen, was wesentlich schwieriger zu erreichen ist. Im Folgenden beschreibe ich meine Sichtweise dieser Grundideen und wie man diese in seiner täglichen Arbeit berücksichtigen kann.

Schon die alten Römer wussten: Divide et impera

Das Agile Framework eignet sich besonders gut in komplexen Umgebungen, bei denen die Kenntnisse der Anforderungen als auch der eingesetzten Technologie nicht sehr hoch sind. In solchen Fällen nimmt man sich einen (Geschäftsvor-) Fall und fängt an, ihn mal zu detaillieren, indem man ihn in kleine Themen zerteilt. Das Konzept ist in der Informatik auch unter dem Stichwort „Divide & Conquer“ bekannt. Ich zerteile ein großes Problem in viele kleine, welche sich einfach lösen lassen. Aber anstatt das große Problem schon mal vollständig zu detaillieren, fange ich schon mal mit der Umsetzung des ersten kleinen Problems an. Habe ich nun so ein kleines Problem gelöst, hole ich mir sofort Feedback ein, welches ich dann wiederum in die weitere Entwicklung einfließen lasse. Dieses Vorgehen wird als Empirisches Vorgehen bezeichnet und unterscheidet sich grundsätzlich von Vorgehensweisen wie dem Wasserfall, bei denen ich die gesamte Lösung komplett beschreiben muss, ohne aber zu dem Zeitpunkt zu wissen, ob dies auch in der Umsetzung funktionieren wird.

Überlebensfähige Software erstellen heißt keine Bananensoftware erstellen

Kenne ich also weder die Anforderung oder die Technologie sehr gut, ist es sinnvoll, erst einmal kleine Funktionen umzusetzen und diese Erfahrung in die weitere Entwicklung einfließen zu lassen, um das Risiko falscher Entwicklung zu minimieren. Der Kunstgriff ist hierbei, die einzelnen Funktionen klein genug zu schneiden, dass diese schnell umgesetzt werden können diese aber groß genug zu schneiden, dass es funktional sinnvoll ist. In diesem Zusammenhang taucht dann auch sehr gerne der Begriff „Minimum Viable Product“ (MVP) auf, der nicht aus dem agilen Framework, sondern dem Lean Management stammt. Es bezeichnet ein minimales überlebensfähiges Softwareprodukt. Kling toll, aber was steckt eigentlich hinter dieser Idee? Ich entwickle ein Softwareprodukt mit einem funktionierenden Funktionsumfang, welcher meinem Kunden eine gute und stabile Funktionalität bietet, die ich dann sukzessive erweitern kann. Es heißt nicht, dass ich möglichst viel Funktionalität mit schlechter Qualität ausliefere. In diesem Fall erstelle ich „Bananensoftware“ (die beim Kunden reift) und verärgere meine Kunden.

Fachbereich und IT, zwei Welten prallen im Agilen aufeinander

Als Bank bedeutet das für mich, dass ich meinen Mitarbeitern diese Denkweise vertraut machen muss und dass ich ihnen den Raum lasse, hier in der Praxis Erfahrung zu sammeln. In der Konsequenz bedeutet dies auch, dass eine Trennung von IT und Business Line nicht sinnvoll ist, denn sowohl das zerteilen der Funktionen als auch die Rückmeldung hierzu bedarf zwingend beider Fraktionen. Der „große Graben“ zwischen IT und Business Lines muss also zugeschüttet werden.

Der große Graben ist auch ein Widerspruch zu einer weiteren Grundidee, das Scrum keinen Unterschied zwischen IT und Business Line macht. In einem Entwicklungsteam sind alle Skills vorhanden, die zur Erstellung des Softwareproduktes erforderlich sind. Das betrifft insbesondere IT und Business Line Mitarbeiter.

Agilität: Gräben zuschütten und miteinander und nicht gegeneinander arbeiten

Ich habe diesbezüglich in einem Projekt die Erfahrung gemacht, dass die daraus resultierenden Verhaltensmuster aufgebrochen werden müssen. Was war passiert? Wir starteten ein agiles Projekt in dem sowohl Mitarbeiter der IT als auch der Business Line waren. Das Ergebnis war, dass am Anfang die umgesetzte Lösung schlichtweg Schrott war und in gelernte Verhaltensmuster zurückgefallen wurde: „Die Implementierung ist schlecht“. „Du hast die User Story nicht gut beschrieben“ und so weiter. Es ging also das übliche Fingerpointing los, jeder hatte Schuld, nur nicht man selber. In der Tat dauerte es mehrere Wochen, bis das Team begriff, dass sie gesamthaft für das Ergebnis verantwortlich sind. Ab da arbeitete man miteinander und es wurde sehr effektiv.

„Der Soldat hat selbsttätig mit Schwimmbewegungen anzufangen.“ Warum selbstorganisierende Teams in Banken Mangelware sind

OK, zwei wesentliche Grundideen haben wir schon, nämlich große Probleme in kleine zu zerlegen und sich deren Umsetzung zeitnah anzusehen, um für die weitere Umsetzung zu lernen sowie gemeinsames Handeln und Denken, um ein gutes Softwareprodukt zu erstellen. Eine weitere neue Grundidee ist die der selbstorganisierenden Teams. Leider beobachte ich immer wieder, dass man Mitarbeitern selbstständiges Handeln über Jahre hinweg abgewöhnt hat. Das Symptom äußert sich meist darin, dass Mitarbeiter selbst kleine Entscheidungen, z.B. ob man etwas linksrum oder rechtsrum entwickeln soll, nicht treffen und diese an das Management in Form von Projektmanagern oder Linienvorgesetzten delegieren. Meist ist dies in sehr hierarchischen Bankinstituten unabhängig von deren Größe zu beobachten. In solch einer Firmenkultur ist agiles Arbeiten schlichtweg nicht möglich, da Scrum keine Hierarchien kennt. In Scrum werden Entscheidungen über die Entwicklung vom Entwicklungsteam getroffen, das Entwicklungsteam ist als Ganzes für das Ergebnis verantwortlich.

Shit happens, aber Agilität hilft, diese schnell zu beseitigen

Dass dabei Fehler passieren, kommt vor, im Gegensatz zu den klassischen Vorgehensmodellen werden diese aber zeitnah im Review identifiziert und können entsprechend zeitnah korrigiert werden. Kein Grund also, ihnen den Kopf abzureißen. In die Hierarchiekerbe schlägt auch, dass der Product Owner die volle Entscheidungsfreiheit darüber hat, was in welcher Reihenfolge umgesetzt wird. Diese Denkweise erfordert, neben einer organisatorischen Änderung, eine bestimmte Firmenkultur, welche ich über einen Change Prozess im Unternehmen einführen und der von allen Führungskräften gelebt werden muss.

Mein Fazit zu Scrum als Framework: Dass sich Scrum als Framework bezeichnet hat seinen Grund, es geht mehr darum, die Grundidee dahinter zu verstehen, als neue Werkzeuge (a fool with his tool) einzuführen. Dies bedeutet aber auch, dass man hierfür einen organisatorischen und auch kulturellen Wandel im Unternehmen durchführen muss. Wird dies unterlassen, ist Agilität zum Scheitern verurteilt.

 

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/

 

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/