Warum Scrum kaputt ist
Die kursiv hervorgehobenen Sätze in der obigen Personenauflistung lassen schon vermuten, dass es in der Praxis so aussieht wie auf dem Bild unten in der Galerie.
Die Planung dauert unabhängig von den Werkzeugen sehr lange und am Ende bekommt man Aufgaben zugewiesen, die in Story Points gemessen werden. Diese Story Points, die eigentlich dazu dienen sollten, eine Vorstellung von der Komplexität einer bestimmten Aufgabe zu bekommen, werden stattdessen zur Zeitmessung verwendet.
Was heißt das nun? Das Team verbringt viel Zeit damit, den eigenen Terminplan zu füllen, statt sich auf die Bereitstellung von Funktionen zu konzentrieren – und man kann dabei nicht einmal seine Geschwindigkeit messen. Dabei wäre das nützlich, um auf der Grundlage früherer Sprints zu verstehen, wie groß der relative Produktfortschritt ist, den ein Team liefern kann.
Ok, aber warum verwenden wir nicht wieder eine Fibonacci-Folge? Oder wie wäre es mit einer Partie Planungspoker?
Aufgaben von Größe S bis L
Aber – kein Grund aufzugeben. Es gibt eine Lösung, wirklich! Nämlich jeder Aufgabe eine Kleidergröße zuzuweisen, um die Messung zu vereinfachen.
Ich finde das eine tolle Idee. Wir müssen uns nur darüber einig werden, ob die gRPC-API eine L- oder M-Aufgabe ist. Wobei das einzige sichere L die Zeit ist, die wir mit der Auswahl einer Methode für diese unproduktive Millimetermessung verloren haben.
Probleme über Probleme
Ein mögliches Szenario: Product Owner und Scrum Master sind nicht im Büro. Einer ist krankgeschrieben, der andere hat Urlaub. Hält das Team trotzdem ein Stand-up-Meeting ab? Ich bezweifle es.
Und was, wenn für jeden Sprint ein individuelles Geschwindigkeitsziel gesetzt wird? Dann sollte man auf mangelhaften Code und unvollständige, aber immerhin automatisierte Tests vorbereitet sein. Wurde erstmal eine statische Kennzahl festgelegt, werden sich die Mitarbeiter daran gewöhnen, sie zu umgehen. Verabschieden sollte man sich dann auch vom Pair Programming und überhaupt von Zusammenarbeit, denn alle sind zu sehr darauf konzentriert, saftige Story Points zu verdienen.
Anderes Szenario: Eine Aufgabe ist zu schwierig aufzuteilen und erfordert eine umfassende Analyse, an der mehrere Teams beteiligt sind und die mehrere Tage dauern kann. Niemand wird sich diese Aufgabe selbst zuweisen – aus Sorge, dafür verantwortlich gemacht zu werden und unproduktiv zu erscheinen.
Und noch ein Beispiel: Man schreibt Tickets für Zehn-Minuten-Aufgaben wie das Formatieren einer Datei, das Aktualisieren einer URL und das Entfernen nicht verwendeter Importe? In einer solchen, ticketgesteuerten Entwicklung dauert selbst das Entrümpeln Ewigkeiten.
Zu viele Köche ...
Recht häufig kommt es auch vor, dass jemand während des Sprints einen Fehler gefunden hat. Lass uns schnell darüber sprechen und mit ... ja, mit wem eigentlich?
Mit dem Teamleiter? Dem Scrum Master? Dem technischen Leiter? Dem Produktverantwortlichen? Dem Service-Owner /Service-Manager? Dem Projektleiter? (Und: Ja, ich habe die Erfahrung gemacht, auch einen Projektmanager im Team mit Scrum zu haben – bitte fragt nicht, warum, aber es ist wirklich so und ich habe Beweise.)
Viel Glück, wir sehen uns beim nächsten Sprint! Scrum wird von der Geschäftsleitung oft als Produktivitätselixier und Heilmittel für jedes unterdurchschnittlich arbeitende Team angesehen, aber die Realität ist so ziemlich das Gegenteil.
Scrum löst die Leistungsprobleme eines Teams nicht. Ein langsames Team wird unter Umständen noch langsamer – und sich die Burn-out-Quote anzusehen, ist schmerzhaft. Ups, ich meinte natürlich Burn-down.