Schon lange, bevor Scrum nicht mehr richtig funktioniert, sind die ersten Probleme in Scrum Events zu erkennen.
Wenn sich eines dieser Probleme bereits in deinem Team anbahnt, dann betrachte es als ein Warnsignal. Und bevor noch Schlimmeres passiert, ergreife die Initiative und gehe die Probleme an. Zu deiner Unterstützung findest du am Ende jeder Problembeschreibung umfangreiche Anleitungen und hilfreiche Tipps, wie du damit starten kannst.
Lass uns direkt loslegen:
Problem 1: Die Planung des Sprints dauert ewig
Dieses Problem könnte viele Ursachen haben.
Angefangen damit, dass das Scrum Team die bevorstehende Arbeit im Refinement nicht besprochen hat oder die Entwickler sich nicht auf den Funktionsumfang verpflichten wollen. Aber die häufigste Ursache ist die Illusion, dass wir die Zukunft planen können, wenn wir nur ausreichend Zeit haben.
Leider ist es so: Wenn wir planen, dann wissen wir vieles nicht. Um dies zu kompensieren, treffen wir Annahmen. Häufig, ohne dass wir uns darüber bewusst sind. Gefährlich wird es, wenn wir diesen auf Annahmen basierenden Plan wichtiger nehmen als die Realität. Unter diesem Gesichtspunkt ist Planung hilfreich, um zu benennen, was wir nicht wissen und noch entdecken müssen. Einem Plan hingegen blind zu vertrauen, ist ignorant.
Um Scrum Teams davor zu bewahren, nur zu planen und nicht selbst zu entdecken, ist das Sprint Planning zeitlich begrenzt:
„Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.“ – Scrum Guide, 2020
Arbeit zu planen, nimmt in Scrum nur einen Bruchteil der Aktivitäten eines Teams ein. Niemals mehr als 1/20. Die restlichen 19/20 der Zeit entdeckt ein Scrum Team die Zukunft, indem es die Arbeit angeht und dabei lernt, was es nicht wusste.
Wenn du nach Wegen suchst, das Sprint Planning deines Teams effektiver und kürzer zu gestalten, dann lies dir diese Anleitung durch:
Wie du das Sprint Planning gestaltest, ohne noch mehr Zeit im Meeting zu verschwenden
Problem 2: Der Sprint kann erst beginnen, wenn die Planung vollständig abgeschlossen ist
Die Arbeit zu planen und die Arbeit auszuführen, gehört in Scrum zusammen.
Beide Tätigkeiten werden in Scrum innerhalb eines Sprints vereint und vom gleichen Team durchgeführt.
„Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt.“ – Scrum Guide, 2020
Werden die Planung der Arbeit und die Ausführung der Arbeit getrennt, entspricht das eher einem wasserfallartigen Entwicklungsprozess und nicht mehr Scrum. Ich glaube, dieses Problem rührt daher, dass bei Jira der Sprint erst gestartet wird, wenn die Sprint Planung abgeschlossen ist.
Wenn du erfahren willst, wie du gutes Sprint Planning in Jira durchführst, dann lies:
Problem 3: Die Entwickler müssen drei Fragen im „Stand-up“ beantworten
Zum Daily Scrum wie zu einem Rapport aufzustehen und dem Scrum Master zu berichten, was gestern gearbeitet wurde, ist ein Überbleibsel aus dem Projektmanagement.
Leider verstehen sich immer noch einige Scrum Master als Projektmanager und fordern die Beantwortung der drei Fragen vehement ein:
- „Was hast du gestern gemacht?“
- „Was willst du heute machen?“
- „Behindert dich etwas bei der Arbeit?“
Dieses Verhalten verhindert das Selbstmanagement der Entwickler.
„Die Developer:innen können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint‐Ziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement.“ – Scrum Guide, 2020
Wenn dies ein Problem in deinem Team ist, dann lies hier weiter:
Wie du ein Statusmeeting in ein Daily Scrum verwandeln kannst
Problem 4: Jeder Entwickler muss an einer eigenen Aufgabe arbeiten
Dass hier etwas nicht stimmt, können wir bereits am Namen „Scrum“ erkennen.
Nach Scrum zu arbeiten, bedeutet eben nicht, dass jeder Entwickler nur einen Arbeitsschritt erledigt und dann die Arbeit zum nächsten Entwickler weiterreicht. Mit „Scrum“ ist keine sequenzielle Bearbeitung der Aufgaben gemeint, sondern dass so wie beim Rugby der Ball innerhalb der Mannschaft hin und her gepasst wird, während sich das Team als eine Einheit auf dem Feld bewegt.
Ich denke, das Problem haben Teams, die diesen Abschnitt des Scrum Guides missinterpretieren:
„Für jeden ausgewählten Product‐Backlog‐Eintrag planen die Developer:innen die notwendige Arbeit, um ein Increment zu erstellen, das der Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product‐Backlog‐Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger. Wie dies geschieht, liegt im alleinigen Ermessen der Developer:innen. “ – Scrum Guide, 2020
In keinem Wort wird hier erwähnt, dass Entwickler Aufgaben für sich planen oder nur Arbeit aus ihrem Spezialgebiet erledigen dürfen.
Wenn dein Team sich mit diesem Problem rumschlägt, dann empfehle ich dir, Work-In-Progress-Limits einzuführen. Wie das geht, erkläre ich im dritten Tipp dieses Artikels:
3 Tipps, wie angehende Scrum Master ein Daily Scrum durchführen, welches Selbstmanagement fördert.
Problem 5: Die Stakeholder sind im Review optional
Sprints sind ein Kompromiss.
Ein Kompromiss aus Fokus auf die Arbeit für das Scrum Team und Vorhersagbarkeit der Ergebnisse der Arbeit für das Unternehmen. Dieser Kompromiss gelingt, wenn das Scrum Team während des Sprints nicht von Anfragen der Stakeholder abgelenkt oder unterbrochen wird, es aber gleichzeitig einen fest definierten Zeitpunkt – das Sprint Review – im Sprint gibt, an dem das Scrum Team mit den Stakeholdern zusammenarbeitet.
„Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder:innen vor und die Fortschritte in Richtung des Produkt‐Ziels werden diskutiert.“ – Scrum Guide, 2020
Sind keine Stakeholder im Sprint Review anwesend, dann zerbricht dieser Kompromiss. Dass das Team nach Scrum arbeitet, liefert nicht die erhofften Resultate für das Unternehmen.
Wenn du nach einer Möglichkeit suchst, ein Sprint Review so zu moderieren, dass Stakeholder begeistert kommen, dann empfehle ich dir, einen Blick in diesen Artikel zu werfen:
„Wie moderierst du ein Sprint Review? 4 Fragen, die dich leiten können“
Problem 6: Die Entwickler müssen in der Demo jedes Ticket vorstellen
Im Wesentlichen ist Scrum die perfekte Aneinanderreihung von Feedbackschleifen, um Produktentwicklung mit minimalem Risiko zu ermöglichen.
Da nichts von diesem Wesen ablenken soll, wird im Scrum Rahmenwerk auf alles Weitere verzichtet. Eine reine Demo ist aber eben noch keine Feedbackschleife. Es fehlt noch die Rückmeldung der Stakeholder, um die Schleife zu schießen. Der Scrum Guide 2020 weist speziell darauf hin, dass eine reine Präsentation zu wenig ist:
„Das Sprint Review ist ein Arbeitstermin und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.“ – Scrum Guide, 2020
Wenn dein Sprint Review einer Demo gleicht, dann schau dir die folgende Anleitung an:
Sprint Review: Wie Product Owner aus einer Demo einen Arbeitstermin machen
Problem 7: Der Scrum Master entscheidet, was im nächsten Sprint verbessert werden soll
Scrum Master sind die Wächter des empirischen Prozesses.
Ihre Aufgabe ist es, dem Scrum Team zu helfen, die wesentlichen Teile ihres Arbeitsprozesses transparent zu machen, damit das Team und die Stakeholder Entscheidungen auf Basis des tatsächlichen Zustands des Produkts treffen. Die Überprüfung und Anpassung geschehen durch die Mitglieder des Scrum Teams. Auf die Sprint Retrospektive bezogen bedeutet das, dass das Scrum Team gemeinsam über die Verbesserungen entscheidet.
„Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern.“ – Scrum Guide 2020
Setzen sich Scrum Master über die Regel hinweg, riskieren sie, dass Verbesserungen nicht umgesetzt werden. Die Wahrscheinlichkeit steigt, dass die Mitglieder eines sich selbst organisierenden Teams Arbeiten erledigen, wenn sie selber bestimmen können, woran sie arbeiten wollen.
Suchst du nach einem einfachen, aber wirkungsvollen Vorgehen, wie du Sprint Retrospektiven so gestalten kannst, dass die Teammitglieder auch die Verantwortung für die Umsetzung der Verbesserungen übernehmen wollen? Dann lies meine Anleitung:
Problem 8: Nur der Scrum Master darf die Retrospektive moderieren
Wenn nur der Scrum Master die Retrospektive moderiert, fördert oder behindert er dann das Selbstmanagement des Scrum Teams?
Ich denke, zu Beginn kann es hilfreich sein, wenn der Scrum Master die Moderation der Retrospektive übernimmt. Somit kann das Scrum Team viel von der Erfahrung des Scrum Masters profitieren. Allerdings glaube ich, wenn dies zum Dauerzustand wird, dann behindert der Scrum Master damit die Weiterentwicklung des Scrum Teams. Die Teammitglieder sind von ihm abhängig und dies verhindert, dass sie Verantwortung übernehmen können. Der Scrum Guide 2020 fasst dies unter dem Wort „sicherstellen“ zusammen:
„Der:die Scrum Master:in dient dem Scrum Team […] dadurch, sicherzustellen, dass alle Events von Scrum stattfinden, positiv und produktiv sind und innerhalb der Timebox bleiben. ”
In Kontext der Sprint Retrospektive kann „sicherstellen“ entweder beuteten, die Moderation selbst zu übernehmen, oder aber, sie einem Teammitglied zu überlassen.
Wenn du mit dem Gedanken spielst, die Moderation der Sprint Retrospektive von anderen Teammitgliedern übernehmen zu lassen, dann bilde sie in der Grundlage von Entscheidungsfindungen aus. Eine Anleitung, um deinem Team die Dynamik in Gruppen näherzubringen, kannst du hier nachlesen: