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/
0 Kommentare:
Kommentar posten