Dieser Artikel ist eine Reaktion auf einen Beitrag bei LinkedIn. Es sollte zuerst eine Antwort auf einen Kommentar werden, ist dann aber zu einem eigenen Artikel herangewachsen. Der Titel dieses Artikels zitiert die Moral des ursprünglichen Beitrags.
Die Situation – wie sie im Beitrag beschrieben wird – ist nicht außergewöhnlich: Eine Organisation mit sehr begrenztem Wissen über Scrum und/oder Agilität beschließt, Scrum einzuführen, wird miserabel beraten und/oder gecoacht und erleidet konsequenterweise damit Schiffbruch.
„Wenn ein Nichtschwimmer ertrinkt, ist das nicht tragisch, sondern konsequent.“
Gerhard Polt
Die Moral des Beitrags, dass Scrum ein Schwindel, ein Betrug, eine Masche ist, fällt für mich in die Kategorie „Frosch ohne Beine hört nichts mehr“. [1]
Was wir in dieser Parabel sehen
- Ein komplettes Managementversagen
Es ist die Aufgabe des Managements, die Spielregeln seiner Organisation festzulegen – wie können sie das tun, ohne die Werkzeuge zu kennen, mit denen die Organisation arbeiten soll – und ohne zu wissen, was diese bewirken? Man kann sicher vieles auslagern, aber nicht das Wissen um und die Kenntnis über die eigene Arbeitsweise, mithin die Kultur der Organisation. Ein Management, das so agiert, muss sich Versagen vorwerfen lassen. - Ein komplettes Scrum Master Versagen
Endlose Prozessdiskussionen und am Ende das Einstellen eines Product Owners „to write user stories“ – wenn ein Scrum Master ersteres bewirkt und letzteres nicht verhindert, dann ist er vermutlich nur ein Ast1). Der Product Owner in Scrum ist nicht ein von außen zugekaufter Storyschreiber, er sitzt im Fahrersitz und hat die Verantwortung für den ROI des Produkts. Diese verantwortungsvolle Rolle muss jemand übernehmen, der das Produkt und die Kunden kennt. Ein Scrum Master, der das seinem Auftraggeber nicht vermitteln kann, ist keinen Pfifferling wert.
Worauf wir achten sollten
Wenn du möchtest, dass sich „wirklich was bewegt“, dann musst du das Management einbeziehen. Passives Management oder Management, das dagegen arbeitet, ist das Ende deiner Bewegung. Ganz gleich, ob das absichtlich oder unabsichtlich, explizit oder implizit geschieht. Sobald die Mitarbeiter „mixed messages“ aus dem Management bekommen, ist das eine rote Flagge.
Wenn du eine Organisation tiefgreifend verändern willst / sollst / musst, dann such dir jemanden, der sich damit auskennt. Jemand mit Erfahrung. Zwei Tage Scrum Master Schulung reichen nicht. Nicht einmal ansatzweise. Denk nicht mal dran. Das Ganze ist komplex genug. Es ist komplex. Es gibt weder eine Blaupause noch ein One-Size-Fits-All. Was heute hier funktioniert, scheitert morgen dort.
„There are no best practices – only adequate practices in context.“ [2]
Organisationsentwicklung – und von nichts anderem reden wir hier – ist eine Operation am offenen Herzen der Organisation – während der Patient am Joggen ist. Das ist definitiv keine Spielwiese für Anfänger – egal wie motiviert oder begabt sie sind.
Was wir erreichen wollen
Im Zentrum unserer Überlegungen sollte am Anfang die Frage stehen, was unser Auftraggeber erreichen möchte, und vor allem warum. Oft hört man zunächst Antworten wie „wir wollen agiler werden“ oder „wir wollen Scrum einführen“. Das ist in der Regel nicht mal das „was“, sondern schon das „wie“, vom „warum“ ganz abgesehen. Aber die Versuchung für uns ist groß, uns darauf zu stürzen, denn das ist schließlich unser Metier.
Vielleicht möchte der Auftraggeber, dass wir ihm helfen, „effektiver zu werden“. Das ist ein sehr schönes „was“. Allerdings bewegt es uns unter Umständen weit vom Thema Scrum und sogar Agilität weg. Abhängig von der Umgebung ist Scrum und/oder Agilität nicht unbedingt die optimale Lösung.
Das Schöne daran: Effektivität ist keine Raketenwissenschaft – schon ein externer Blick allein genügt, um in einer Organisation eine Steigerung von 10 bis 30% bewirken zu können – wie gesagt, ganz unabhängig von Agilität. Diese Erkenntnis ist nicht auf meinem Mist gewachsen, das hat mir vor Jahren ein Prozessberater vom Managementzentrum St. Gallen verraten. Vor diesem Hintergrund betrachtet sind einige Erfolgsmeldungen agiler „Transformationen“ nicht mehr ganz so spektakulär.
Scrum ist nicht die Antwort auf alle Fragen
Was ich aus meiner Erfahrung sagen kann: Ich empfehle heute Scrum nur noch in Ausnahmefällen. Das heißt nicht, dass ich kein Fan von Scrum bin, im Gegenteil (dreifache Verneinung, cool oder?).
Es ist nur so, dass Scrum einige Voraussetzungen mitbringt, ohne die es nicht – oder nicht gut – funktioniert. Die allermeisten Organisationen, die ich kenne, sind so weit von dem Denken und der Arbeitsweise weg, die Scrum voraussetzt, dass sie mit einer Scrum Einführung schlicht überfordert sind.
Da schlägt dann entweder der kompensatorische Rückkopplungseffekt aus dem zweiten Gesetz der Fünften Disziplin [3] zu: The harder you push a system, the harder it will push back.
Oder man verlegt sich auf das sogenannte „cherry-picking“ – man sucht sich die Teile heraus, die man glaubt, (einfach) erreichen zu können. Heraus kommt dann ein hybrides Franken-Scrum, das in der Regel das Schlechte aus mehreren Welten in sich vereint.
Darüber hinaus passt Scrum auch nicht wirklich für alle Umgebungen. Vor einiger Zeit habe ich dazu schon mal einen Artikel veröffentlicht.
Eine Antwort auf die meisten Fragen
Heutzutage ist meine generelle Empfehlung: Kanban. Das ist wesentlich universeller einsetzbar, wesentlich risikoärmer und erzeugt wesentlich weniger Widerstand. Es ist in mehrerlei Hinsicht invers zu Scrum:
- Es ist evolutionär, nicht revolutionär (Kaizen vs. Kaikaku)
- Es legt den Startpunkt der Veränderung fest, nicht den Endpunkt
Der zweite Punkt verdient noch ein paar Worte: Scrum ist es egal, wo du mit deiner Organisation heute stehst – es sagt dir, wo du hinmusst: In ein Setup, das dem Scrum Guide entspricht. Punkt. Wie du dorthin kommst? Dein Problem. Frag den Scrum Master. Dummerweise ist die Chance recht groß, aus dem gigantischen Topf zertifizierter Scrum Master einen Ast1) zu ziehen.
Kanban ist das genaue Gegenteil: Fest steht der Startpunkt, nämlich genau das was deine Organisation heute tut. Ab da ist alles eine endlose Reise in vielen kleinen Schritten hin zu der Arbeitsweise, die für deine Organisation die passendste ist. Das erste Ziel bei Kanban ist nicht Kanban, sondern dass deine Organisation „Fit for Purpose“ ist [4].
Fazit
- Ohne Unterstützung vom Management gibt es keine (nachhaltige) Veränderung
- Organisationsentwicklung ist nichts für Anfänger
- Scrum ist gut – wenn es zur Organisation und zum Problem passt – sonst eher nicht – siehe auch [5]
- Kanban ist universeller einsetzbar, sozial verträglicher und weniger riskant
Fußnoten
1) Kent Beck hat mal in einem Interview gesagt, statt CSM müsse es eigentlich AST heißen: Attended Scrum Training. *Like*
Referenzen
[1] https://www.spitzenwitze.de/schwarzer-humor/7320/
[2] Larman, Craig & Vodde, Bas: Practices for Scaling Lean & Agile Development, 2010, Addison-Wesley, S. 4
[3] Senge, Peter M.: Die fünfte Disziplin, 11. Auflage 2011, Schäffer-Poeschel Verlag Stuttgart, S. 74ff.
[4] Anderson, David J. & Bozheva, Teodora: Kanban Maturity Model, 2021, dpunkt.verlag, S. 21ff.
[5] Agilität trifft Kultur – Erfolg oder Desaster?