Welches ist das wichtigste Scrum Event?
Eine Frage, die jedem Scrum Master bestimmt schon mal gestellt wurde. Mir wurde sie in Vorstellungsgesprächen gestellt, ich habe sie in Vorstellungsgesprächen gestellt. Mir wird die Frage regelmäßig in Scrum Trainings oder Workshops gestellt. Und sie versteckt sich auch hinter dieser häufig zu hörenden Aussage:
„‚Scrum by the book‘ machen wir nicht, wir haben einiges angepasst und manches aus dem Scrum Guide auch weggelassen.“
Willem-Jan Ageling hat diese Frage vor einigen Jahren auch bei LinkedIn gestellt.
Hier eine Antwort der Community:

Über 50 % der 850 Befragten haben mit „Sprint-Retrospektive“ geantwortet.
Auf den ersten Blick scheint die Sprint-Retrospektive das wichtigste Event in Scrum – oder wurde hierbei etwas übersehen?
In den über 100 Kommentaren zu dieser Umfrage finden sich viele Gründe dafür.
Eine der prominentesten Antworten ist wohl:
„Ich sage immer: Beginnen wir einfach mit der wöchentlichen Retrospektive, dann wird sich alles andere von selbst ergeben.“
Sie stammt von Sohrab Salimi, einem angesehenen Scrum Trainer bei der Scrum Alliance. Damit hat Sohrab nicht ganz unrecht. Regelmäßige Reflexion über die Zusammenarbeit empfiehlt auch der Scrum Guide.
„Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief.“
Warum wählen so viele die Sprint-Retrospektive?
Ein plausibler Grund: Die tägliche Arbeit vieler Scrum Master ist stark auf Moderation und Coaching ausgerichtet. Shastri, Shastri, Hoda und Amor (2021) befragten 47 agile Praktiker zu typischen Aktivitäten von Scrum Mastern. 69 % nannten die Facilitation der verschiedenen Events und das Entfernen von Impediments, ebenfalls 69 % Mentoring und Coaching auf dem Weg zur Selbstorganisation. Wer Retrospektiven häufig moderiert und dort sichtbare Fortschritte erlebt, nimmt sie leicht als den stärksten Hebel wahr.
Aber:
Reicht dies als Motor für Verbesserung?
Im PSM-3-Bootcamp haben Marc und ich den Teilnehmern in der ersten Woche auch die Frage gestellt:
„Aus Sicht eines Scrum Masters: Welches Scrum Event hältst du für das wichtigste – und warum?“
Im Camp zeigte sich ein etwas anderes Bild.
Zwar hat die Sprint-Retrospektive weiterhin viele Stimmen bekommen, allerdings dicht gefolgt vom Sprint-Review. Bei Willem-Jans Umfrage spielte das Sprint-Review auf dem letzten Platz. Und im Unterschied zur Umfrage auf LinkedIn haben wir auch nach einer Begründung der Wahl gefragt.
Der Tenor lautete:
Das Feedback der Stakeholder ist entscheidend für den Erfolg des Produkts.
Was sich auch mit der Beschreibung im Scrum Guide deckt:
„Während des Events überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist.“
Aus meiner Sicht ist das der entscheidende Punkt:
Eine Retrospektive reicht nicht.
Es braucht auch Feedback. Und zwar nicht nur Feedback durch die Mitglieder des Teams, sondern von außen. Feedback von den Personen, die am Ende über den Erfolg des Produkts entscheiden.
Der Weltklasse-Geiger Joshua Bell bestätigt dies in einem Experiment. Er spielte inkognito in der U-Bahnstation L’Enfant Plaza in Washington. Von etwa 1.097 Passanten hielten nur sieben inne, um zuzuhören. Aus diesem Beispiel können wir viele Schlüsse ziehen. Mir geht es darum: Wer ein Instrument übt, wird durch eigene Reflexion zwar besser, aber erst das Feedback von außen – etwa von einem Lehrer oder Publikum – zeigt, ob die Musik wirklich ankommt. Das bestätigt auch die Forschung: John Hatties Meta-Analyse „Visible Learning“ (2007) hat gezeigt, dass Feedback zu den stärksten Einflussfaktoren für nachhaltiges Lernen gehört. Ohne externe Rückmeldung ist Lernen nur begrenzt erfolgreich.
Sich mit Feedback von außen konstant an Veränderungen anzupassen – darum geht es beim empirischen Arbeiten.
Der Scrum Guide beschreibt es so:
„Deren Summe [der Inkremente] wird im Sprint-Review vorgestellt, womit Empirie unterstützt wird.“
Wenn die Sprint-Retrospektive nicht das wichtigste Event in Scrum ist, dann ist es also das Sprint-Review?
Jetzt wird es interessant.
Im Sprint geht es doch darum, ein Ziel zu erreichen – was ist, wenn der Setzung davon keine Beachtung geschenkt wird?
Bevor wir also vorschnell beschließen, dass das Sprint-Review das wichtigste Event ist, sollten wir noch einmal kurz über Sprint-Planning und Daily Scrum nachdenken.
Betrachten wir das Extrem und nehmen an, dass ein Scrum Team dem Sprint-Planning keine Beachtung schenkt und nur halbherzig ein – oder gar kein – Sprintziel definiert. Nehmen wir auch an, dass das Daily Scrum alles andere als gut ist und einem reinen Statusreport gleicht, in dem die Entwickler schildern, womit sie ihre Zeit gestern verbracht haben.
Was wären die Auswirkungen auf das Sprint-Review?
- Vielleicht verkommt das Sprint-Review zu einer Demonstration eines Sammelsuriums von Fehlerbehebungen, technischen Details und zusammenhangslosen Features.
- Vielleicht verlieren die Stakeholder das Vertrauen ins Team. Das Team scheint zwar immer beschäftigt, doch eine gebündelte Wirkung entfaltet seine Arbeit nicht.
- Vielleicht schreiben die Stakeholder das Team ganz ab und bleiben dem Sprint-Review fern. Dadurch verliert das Unternehmen die Außensicht auf die Entwicklung – und das Risiko steigt, am Markt vorbei zu entwickeln.
Vor den Auswirkungen dieser Ziellosigkeit warnt der Scrum Guide jedes Unternehmen:
„Die Scrum-Artefakte und der Fortschritt in Richtung der vereinbarten Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken.“
Lass uns kurz mal innehalten und zusammenfassen:
Die Sprint-Retrospektive ist nicht das wichtigste Event, wenn das Feedback von außen fehlt. Das Sprint-Review bietet zwar die Möglichkeit für dieses Feedback, aber ohne ein gutes Ziel aus dem Sprint-Planning kann sich Scrum zum Schreckgespenst für jedes Unternehmen entwickeln.
Und nun?
Aus meiner Sicht ist die Frage eine Falle.
Die Wahrheit ist doch:
Alle Scrum Events sind gleich wichtig. Dieser Satz im Scrum Guide verdeutlicht das:
„Das Scrum-Rahmenwerk, wie es hier beschrieben wird, ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum.“
Diese „Unveränderlichkeit“ von Scrum führt häufig zu Kontroversen. Denn der Scrum Guide sagt auch: Wenn du kein „Scrum by the Book“ machst, machst du kein Scrum. Punkt.
Was viele dabei nicht verstehen: Es geht eben nicht darum, alle Scrum Events bei ihrem Namen zu nennen, alle Rollen zu besetzen oder alle Timeboxen einzuhalten, sondern darum, Unternehmen den ganzen Vorteil eines empirischen Ansatzes bei der Produktentwicklung zu ermöglichen:
Das finanzielle Risiko auf einen Monat zu beschränken.
Um dieses Versprechen einzulösen, beschreibt das Scrum-Rahmenwerk eine Reihe von Feedbackschleifen, die so verkettet sind, dass empirische Prozesssteuerung etabliert wird. Damit Scrum keine unnötige Arbeitszeit der Mitarbeiter vergeudet, beschreibt das Scrum-Rahmenwerk nur die minimale Menge an Schleifen, die nötig ist, um das finanzielle Risiko in der Entwicklung effektiv zu minimieren.
Minimal bedeutet aber auch:
Wird etwas weggelassen, funktioniert Scrum nicht mehr als Risikomanagement-Werkzeug.
Somit muss die einzig professionelle Antwort auf die Frage „Welches Scrum Event ist am wichtigsten?“ lauten: „alle“.