Worst Scrum ever!

Bild: Pexels / Karolina Grabowska - Lizenz

Nach über 10 Jahren als Scrum Master, Agile Coach und in anderen "agilen Rollen" ist so einiges an Erfahrungen zusammengekommen die ich mit der Zeit gemacht habe, sowohl im Guten als auch im Schlechten. Basierend darauf gibt es eine Frage, die mir immer wieder gestellt wird: ob es eine erkennbar schlimmste Umsetzung von Scrum unter denen gegeben hat, die ich erlebt habe. Und tatsächlich gibt es sie, die eine, die so übel war, dass sie wirklich aus allem heraussticht. Haltet Euch fest.

Der Kunde war ein Mittelständler aus Süddeutschland. Scrum war dort ein Jahr zuvor von einer grossen, mit A beginnenden Unternehmensberatung eingeführt und als revolutionäre Prozess-Optimierung angekündigt worden. In der Wahrnehmung des oberen Managements liessen die sichtbaren Verbesserungen aber auf sich warten, weshalb ein externer Experte (ich) überprüfen sollte, ob das Vorgehen tatsächlich so umgesetzt wurde wie gedacht. Ich begann entlang der Wertschöpfungskette.

Die erste Überraschung erwartete mich gleich zu Beginn, denn am Anfang der Wertschöpfungskette befand sich eine Fachabteilung, die ein Lastenheft verfasste, also eines jener Telefonbuch-dicken Dokumente, die alles an Wünschen enthalten, was der beauftragenden Einheit sinnvoll erscheint. Nichts davon war durch Marktforschung oder Kundenfeedback validiert, nichts davon war durch eine Machbarkeitsanalyse oder eine Aufwandsschätzung gegangen.

Dieses Lastenheft ging im nächsten Schritt an das Anforderungsmanagement, das den Auftrag hatte, es in User Stories herunterzubrechen. Die Unternehmensberatung mit A hatte dafür eine Anleitung hinterlassen, der zufolge alle User Stories mit "als User möchte ich" beginnen mussten (der Zwecksatz fehlte dagegegen) und klein genug sein mussten, um von einem einzigen Entwickler in einem Tag umgesetzt werden zu können.

Um dieses Anforderungsmanagement zu Höchstleitungen anzuspornen, wurde seine Leistung an der Menge der geschriebenen User Stories gemessen. Um möglichst viele erzeugen zu können wurden diese folgerichtig noch kleiner als gefordert, zwei an die ich mich erinnern kann waren "Als User möchte ich, dass sich das Dropdown-Menue öffnet wenn man es anklickt" und "Als User möchte ich, dass das geöffnete Dropdown-Menue anklickbare Items enthält". Insgesamt waren es tausende.

Die so verfassten User Stories gingen als nächstes in das so genannte "Planning I", in dem der IT-Chef und die Architekten sie auf einen Zeitstrahl verteilten, der bis weit in das nächste Jahr hineinreichte. Aufgrund der schieren Masse (nochmal: tausende) wurden dabei nicht alle genau angeschaut, das Hauptkriterium war, dass ungefähr gleich viele in jedem Monat landeten. "Langfristig mittelt sich das", wurde als Begründung für dieses Vorgehen genannt.

Kurz vor Beginn eines Monats (der hier einem Sprint entsprach) folgte jeweils das "Planning II". Die Architekten und der in diesem Moment erstmals beteiligte Product Owner schätzten für jede der für diesen Monat eingeplanten User Stories den Aufwand und entschieden, welchem Entwickler sie zugewiesen werden würden. Zusätzlich dazu verfassten sie neue User Stories für dringende Bugs ("Als PO möchte ich, dass Bugticket XY im nächsten Sprint gefixt wird") und wiesen auch die zu.

Am ersten Arbeitstag des Monats, bzw. Sprints folgte schliesslich das "Planning III". In dem wurde nacheinander jeder Entwickler in einen Raum gebeten, in dem er von dem PO, den Architekten und seinem Abteilungsleiter (diese Rolle war in Personalunion auch Scrum Master) erwartet wurde. Dieses Kommittee erklärte dem einzeln vor ihm stehenden Entwickler, welche Arbeit für ihn eingeplant war, erlaubte es ihm, Verständnisfragen zu stellen und forderte ihn auf die Lieferung zuzusagen.

Dass diese Zusage auch eingehalten wurde, wurde im Sprint in den Daily Scrums sichergestellt. Die Scrum Teams (jeweils 15 bis 25 Entwickler) versammelten sich in einem Raum, der Abteilungsleiter/Scrum Master filterte das digitale Sprint Backlog nach Bearbeitern und forderte nacheinander jeden auf vorzutreten und einen Statusbericht abzugeben. Da dieser Termin länger als eine Stunde war, konnte jeder direkt nach seinem Bericht zurück an die Arbeit, um so produktiver zu sein.

Erfahrungsgemäss zeigte sich in den meisten Sprints etwa in ihrer Mitte, dass sie zu optimistisch geplant waren. Um das auszugleichen, forderten die Abteilungsleiter/Scrum Master die Entwickler zu Überstunden auf oder verschoben User Stories zu anderen, die noch nicht im Rückstand waren. Neu entdeckte Bugs wurden in das "Bug Backlog" verschoben, aus dem alle die nicht dringend waren in einem der halbjährlich stattfinden "Bugfixing-Sprints" eingeplant wurden.

Im am Ende des Sprints stattfindenden Review Meeting überprüften die Architekten, die Product Owner und die Abteilungsleiter/Scrum Master ob alle User Stories wie geplant fertiggestellt worden waren, falls das nicht der Fall war konnten einzelne Entwickler in dem Raum geholt werden um ihren Rückstand zu erklären. Die Ergebnisse des Reviews wurden im Anschluss schriftlich dem Steuerungskommittee mitgeteilt, in dem u.a. der IT-Chef und die beauftragende Fachabteilung sassen.

Retrospektiven gab es keine. Sie hatten wohl früher stattgefunden, waren aber wegen Ineffektivität wieder abgeschafft worden.

Wie man sich denken kann, konnte ich bereits nach wenigen Tagen mit einer umfangreichen Liste an identifizierten Missständen und konkreten Handlungsempfehlungen aufwarten. Ich hatte schon geahnt, dass sie keine Begeisterung auslösen würden, und genau so kam es. Ich sollte doch stattdessen bitte "pragmatische Lösungen" erarbeiten, die ohne grundlegendes Infragestellen der bestehenden Prozesse umsetzbar wären. Das wollte ich nicht, und als Folge dessen beendete die Firma unsere Zusammenarbeit.

Und das ist sie, die Geschichte der schlimmsten Umsetzung von Scrum, die ich jemals erlebt habe. Ich habe später noch mitbekommen, dass in den folgenden Monaten über die Hälfte der Angestellten aus der IT gekündigt hat und dass weitere Unternehmensberatungen beauftragt wurden. Ob es eine Moral gibt, die man daraus ziehen kann weiss ich nicht, vielleicht ist es diese hier: egal wie vermurkst Dir Deine agile Transformation erscheinen mag - irgendwo ist es schlimmer.