Warum „Scrum“ eigentlich „murcS“ heissen sollte! Eine Abrechnung mit Scrum in vier Akten

Scrum ist eine moderne Methode zur Umsetzung von agilem Projektmanagement. Agiles Projektmanagement wiederum beschreibt die Eigenschaft von Projekten, flexibel und rasch auf veränderte Umweltbedingungen reagieren zu können. Zudem soll Scrum dabei helfen, die Effizienz im Team zu steigern und für einen kontinuierlichen Fluss an den Output zu sorgen. Aber effizienz hat ihren Preis und manchmal gefährdet der Scrum Prozess den Erfolg an sich.

Sometimes Scrum becomes this overarching process where you do nothing consistently except Scrum rituals and making those Scrum rituals seem successful.

Matthew Gaiser

Vor allem in Kontexten in denen es um die Programmierung von komplexen Produkten geht, ist Scrum beliebt und weit verbreitet und ein Erfolgsmodell. Scrum setzt auf eine Reihe von wunderbaren Werten: Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt und vertritt eine wundervoll inspirierende Philosophie:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Aber was bleibt im Alltag davon übrig? Ist Scrum das Allheilmittel im modernen Projektmanagement. Ist Agilität nur der Scrum-Methode vorbehalten? Die Erfahrungen aus der Praxis zeichnen ein katastrophales Bild. Eine Abrechnung in vier Akten nach einem Jahr Scrum im Bildungsbereich:

1. Das Scrum Manifest: Mit Regeln und Rollen gegen Individualität und Kreativität

Scrum bietet ein umfangreiches Toolset von Regeln und Rollen.  Es gibt ein Scrum Guide und eine Philosophie die geradezu mantraartig bis religiös kommuniziert, wiederholt und intensiv vor- und nachgelebt werden muss. Regeln schützen vor Störungen, Struktur schafft Verlässlichkeit. Ja das ist soweit auch in Ordnung und gewollt. Aber diese Regeln zerstören all jene Kreativität die eben in bestimmten Arbeitsbereichen notwendig ist. Die Rollen in Scrum schaffen zudem eine Ungleichverteilung der Arbeitslast und eine Entfremdung vom Produkt – jedenfalls bei denen die explizit aus der Umsetzung herausgehalten werden. Während die Entwickler stumm geschaltet auf die Umsetzung fokussieren sollen, soll der Produkt Owner ein Produkt verkaufen, dass er nicht kennt. Der Scrum Master wird des Weiteren nur dazu abgestellt zu schauen, das bitte auch die Scrum-Regeln eingehalten werden.

The problem is, you are fighting the nature of Scrum as it primarily cares about velocity. What gets measured is what gets focused on and what Scrum measures is speed of output with the output judged from the user side only by the product owner. That metric does not value many behaviors associated with great developers.

2. Alter Wein in teuren Schläuchen – Warum das Produkt „Scrum“ gar nicht so innovativ ist wie es vorgibt

Mit einem unfassbar ausgestalteten Set an neuen Begriffen versucht Scrum seine Neuartigkeit zu unterstreichen. Treffen heißen nicht mehr nur „Meeting“, sondern „Daily“, Aufgabenbeschreibungen avancieren zu „Stories“, Aufgabenlisten werden zum „Backlog“ und klassische Feedbackgespräche mit Kunden zu umfangreichen „Review-Meetings“ und interne  Teamgespräche zu „Retrospectives“. All diese Methoden und Objekte, in Scrum „Artefakte“ genannt, sind nicht neu, nur ihre Benennung ist anders. Sie will symbolisieren „ich bin modern ich heiße anders, ich bin trendy“.

Die Aufgaben werden in Scrum typischerweise in Zyklen, „Sprints“ genannt, von 3-4 Wochen geplant, es gibt eine Visualisierung, das „Scrum Board“, und eine Quantifizierung des Outputs in Form des „Burn-Down-Charts“, in dem täglich manuell abgetragen wird, wie viele Aufgaben erledigt wurden, um am Ende des Sprints idealerweise bei null offenen Aufgaben anzukommen. Den Aufgaben an sich werden zudem „Story-Points“ zugeordnet, die vom Entwicklerteam im „Planning“ mit speziellen Scrum Cards geschätzt werden müssen. Diese „Story-Points“ sind Gewichtungen, aber sie haben bewusst keine Einheit. Sie sind nicht äquivalent zu Zeit oder Komplexität, sie sind eine mystische Einheit. Hürdensammlungen werden zu „Impediments“ und Entwickler zu „Developern“.

Während diese andere Sprache vll. die Neuartigkeit bekunden oder zur Reflexion des agilen Manifests anregen soll wirkt sie auf Dauer mindestens artifiziell, auf den reflektierten Mitarbeiter vll. mitunter auch albern. Das Anderssein wird zum Selbstzweck und die neuen Begriffe sollen darüber hinwegtäuschen, dass das ganze eigentlich gar nicht so innovativ ist. Die Begriffe sind zudem auch tlw. gar nicht treffend. zwei Beispiele:

Sprint:
Ein „Sprint“ ist ein Kurzstreckenlauf, bei dem ich alle Kraft einsetze.  Nach dem Sprint bin ich erst mal erschöpft. Es ist kein ausdauernder Lauf, sondern ein einmaliger Aufwand. Eine Iteration dagegen ist etwas, das sich in ähnlicher Weise stets wiederholt. Der begriff „Sprint“ drückt damit gar nicht das aus, was Scrum eigentlich meint, nämlich eine „kurze Iteration“ auf die die nächste folgt.

Backlog:
Dann gibt es noch die Backlogs: Product-Backlog und Sprint-Backlog. Ist ein Backlog eine „Rückstandsliste“? In gewisser Weise ja, aber der passendere und einfachere Begriff wäre vielleicht „Aufgabenliste“. Doch der klingt eben nicht so fancy und so gar nicht neu.

Aber Scrum entfaltet sich nicht von alleine. Hinter dem Modell steckt eine ganze Industrie mit absurd klingenden Titeln und Zertifikaten, mit teuren Trainern, Schulungen und Mantras. Original-Zitat eines Trainers: „Der Scrum Master hat die Pflicht, im Unternehmen für Scrum zu werben“. Scrum selbst ist das Produkt, das verkauft werden will, es wurde entwickelt von Ökonomen und wird vertrieben wie beim Struktumarketing.

3. Agilität anders formuliert: Kontrolle schafft Sicherheit

Täglich treffen sich die Entwickler in der benannten Timebox „Daily“ um eine Viertelstunde (aber nicht länger) über das Alltagsgeschäft zu reden, Product Owner und Scrum Master hören eifrig zu und stellen ggf. blöde Fragen (sollen sie egtl. nicht, aber tun sie da sie ja mit den Verfahren und Umsetzungen nicht vertraut sind). Diese Methode soll dazu führen, dass das Entwicklerteam miteinander spricht, was anscheinend bei Programmierern selten sein muss.

The fact of being observed changes the way people work. In creative fields, it’s for the worse. It’s almost impossible to work creatively if one has to justify the work on a day-by-day basis.

Scrum zielt darauf ab, Strukturen zu etablieren, die die Freiheit eingrenzen und dadurch Erwartbarkeit und Planbarkeit in komplexen Prozessen schaffen. Das ist vom Ansatz her legitim, aber es ist eben zweifelhaft, ob diese Art von Methode dazu führt, dass dieses Ziel mit bestmöglicher Effizienz erreicht wird. Gerade in Arbeitskontexten, die Kreativität erfordern scheitert Scrum zunehmend. Gerade bei sehr komplexen Produkten, bei deren Umsetzung Scrum ja seine Vorteile auszuspielen verspricht, führt Scrum häufig zu Chaos, Indifferenzen, inhomogenen Arbeitsverteilungen und Entfremdung vom Produkt.

Schlechte Qualität dient der Velocity

Scrum zielt darauf ab, schnell funktionierende Ergebnisse zu liefern. Qualität ist dann erreicht wenn schnell neue funktionale Inkremente ausgeliefert werden können. Quantität statt Qualität, denn Qualität erfordert eine tiefere Auseinandersetzung mit dem Produkt. Scrum honoriert das jedoch nicht. Im Gegenteil – was nicht messbar ist verschlechtert die Velocity und damit den gemessenen Erfolg. Umso dramatischer wenn technische Kenntnisse des Product Owners so schlecht sind, dass er kein tiefes Verständnis des Produkts besitzt.

• Great developers are usually defined by their ability to develop robust code. Unless the product owner is technical, Scrum massively devalues that as the product owner isn’t evaluating the code. It is feature driven and „it runs“ is a functional standard for the provided user stories.
• Great developers are usually defined by their ability to write code which has value both now and in the future. Scrum projects think of everything in two week periods. There is no future.
• Great developers are usually defined as those who can solve tough problems. Scrum encourages picking work that can easily be done and rapidly churned out at a steady pace. A tough problem is a developer being slow on getting the tickets done.
• Great developers are often sought out for advice and for second opinions. But any time doing that is less time spent churning out tickets, so their velocity falls

Und „daily“ grüßt der Scrum murcS – Die Abrechnung

Der begriff Scrum geht auf die Metapher zurück, dass viele Individuen intensiv in einem Gemenge, möglicherweise bei den Dailys miteinander in Kontakt treten. Ähnlich wie beim Rugby um den Ball gekämpft wird, ist die Suche nach Sinn und Ordnung bei Scrum anscheinend nur durch Chaos möglich. Aber die Kritik ist viel konkreter. Eine Übersicht über die in der Praxis entstehenden nervigsten und gefährlichsten Probleme bei der Implementation von Scrum:

• Die Daily „Status Meetings“ nerven und avancieren in der Praxis zu oft zu Treffen in denen die Entwickler sich und Ihr tun vor den anderen legitimieren sollen: „Devs have to justify themselves to “scrum masters” and “product owners” and layers of non-technical management.“
• Die Iteration „Sprints“ sind künstlich. Ihre Länge ist grundlos definiert und orientiert sich eher an ökonomischen Gesichtspunkten als an projektspezifischen sinnvoll gesetzten Meilensteinen. Zudem hat Scrum eine Obsession zu viel zu kurzen Iterationen.
• Die vielbeworbenen „Inkremente“ sind keine „Inkremente“ sondern nur künstlich definierte Sprint-Ziele.
• Die vielen Scrum-Events stören den „Worflow“, die Einmischung Projekt-fremder Rollen (Produkt-Owner und Scrum-Master) nervt.
• Kreativität wird im Kern und grundsätzlich durch Scrum behindert: Was nicht als Aufgabe definiert ist hat keinen Raum. Der Blick nach Links und Rechts oder gar über den Tellerrand wird bewusst und substantiell unterbrunden.
• Die Rollen in Scrum führen zu ungleichverteilter Verantwortung und inhomogener Arbeitslslast. Scrum-Master und Product-Owner sind rigoros von der Umsetzung ausgeschlossen und entfremden sich vom Produkt.

Often, it’s the best employees who fall the hardest when Agile/Scrum is introduced, because R&D is effectively eliminated, and the obsession with short-term “iterations” or sprints means that there’s no room to try something that might actually fail.

Scrum ist eine Mode die gut und gerne erprobt werden darf. Scrum ist aber niemals ohne Reflexion und formative Evaluation einzusetzen, sonst wird es gefährlich. Wer die Harmonie in Teams der Ordnung durch virtuelle Regeln opfert, der riskiert das Scheitern eines Projekts. Wer Intransparenz unter dem Mantel eines agilen Effizienzanspruchs verkauft begeht Vertrauensbrüche, die nur mit viel Aufwand geheilt werden können. Wer Harmonie und Vertrauen einem Trend opfert, der Gutes verheißt, aber Probleme bringt, hat effizientes Projektmanagement nicht verstanden.