Die Sprint Review: Quelle für Kollaboration und Kommunikation

Jeder Scrum Master kennt Definition und Regeln der Sprint Review aus dem Scrum Guide in- und auswendig. Das Team präsentiert das Erreichte – das aktuelle Inkrement – und gewinnt wertvolles Feedback. So bekommen alle einen Ausblick auf die Ziele und können diese dann gemeinsam und kollaborativ anpassen. Die Review hat aber Potenzial für viel mehr. Dazu lohnt der Blick auf die ursprüngliche Intention hinter dem Framework. Ken Schwaber und Jeff Sutherland, die Begründer von SCRUM, hatten eine ziemlich genaue Vorstellung, was sie mit dem Framework erreichen wollten. Ken und Jeff ließen sich bei der Entwicklung von SCRUM von folgender Aussage motivieren: „Ermutigt Entwickler:innen ins Feld zu gehen und zuzuhören, was Kund:innen und Händler:innen zu sagen haben.“ (Takeuchi und Noaka, 1986).

Doch verhindert ein traditionelles Meeting nicht die Kollaboration zwischen Entwickler:innen und User:innen? Entwickler:innen und Nutzer:innen ziehen sich häufig nach dem Meeting wieder zurück und warten dann bis zur nächsten Review auf Feedback. Nein, das muss nicht so sein. Die Review kann aber für viel mehr genutzt werden als nur für eine reine Demonstration und einen Ausblick auf die folgenden Sprints. Durch das Beobachten und die Analyse der Teilnehmer können wertvolle Helfer für die Anforderungsermittlung und Unterstützer bei einer Transformation gewonnen werden.

Aber auch die Abwesenden liefen Ausgangspunkte für ein weiteres Vorgehen. Durch einen systemischen Ansatz werden Gründe für das Fernbleiben gesucht und Lösungen gefunden. Agile Projekte können erst mit der Kollaboration zwischen Entwickler:innen und Stakeholder:innen ihre Stärken richtig ausspielen. Mit den richtigen Stakeholder:innen, gewonnen aus der Review, können dann die richtigen Strukturen ausgewählt werden, um ideale Ergebnisse bei optimaler Ausnutzung der Zeit zu erzielen. Dazu gehören exemplarisch Design Studio, Domain Storytelling oder auch Eventstorming.

Nils Hyoma wird in seinem Vortrag von seinen Erfahrungen von einem Projekt berichten, in dem eine disruptive Software erfolgreich agil eingeführt worden ist. Dabei wurden viele kritische Stakeholder:innen eingebunden und wurden durch Kollaboration zu Unterstützern der neuen Lösung.