Sprint Review im traditionellen und hybriden Umfeld So etablieren Sie Demos als Ersatz für Statusmeetings

Sie arbeiten in einem traditionellen oder hybriden Umfeld und möchten dort die Vorteile eines Sprint Reviews genießen? Das geht leichter, als Sie vielleicht vermuten, sagt Michael Wittemann. Mit Hilfe von sieben einfachen Regeln ersetzt der Autor Statusmeetings durch Demos am Projektgegenstand.

Management Summary

Sprint Review im traditionellen und hybriden Umfeld So etablieren Sie Demos als Ersatz für Statusmeetings

Sie arbeiten in einem traditionellen oder hybriden Umfeld und möchten dort die Vorteile eines Sprint Reviews genießen? Das geht leichter, als Sie vielleicht vermuten, sagt Michael Wittemann. Mit Hilfe von sieben einfachen Regeln ersetzt der Autor Statusmeetings durch Demos am Projektgegenstand.

Management Summary

Sie arbeiten in einem traditionellen oder hybriden Umfeld und möchten dort die Vorteile eines Sprint Reviews genießen? Das geht leichter, als Sie vielleicht vermuten! Anhand eines Beispiels zeige ich Ihnen, wie Sie dieses Review Meeting in Ihrer Organisation als Ersatz für Statusmeetings einführen können. Dies möchte ich mit diesem Artikel am konkreten Beispiel der Einführung von regelmäßigen Produkt-/Projekt-Demos in einem traditionellen Projektumfeld darstellen. Ich selbst unterstützte den Projektleiter in diesem Vorhaben als Gruppenleiter.

Was ist ein Sprint Review?

Das Sprint Review ist in Scrum ein verpflichtendes Meeting zum Informationsaustausch am Ende eines jeden Sprints. Sein Ziel ist es, die Ergebnisse des abgelaufenen Sprints vorzustellen und diesbezüglich Feedback von den Stakeholdern einzusammeln. Der auch als "Demo" bezeichnete Sprint Review dient zur Überprüfung der zuletzt erstellten Produktinkremente und – wenn nötig – zur Anpassung des Product Backlogs. Die Sprintziele werden hierfür mit den erzielten Ergebnissen abgeglichen, indem der Product Owner jedes Backlog-Item hinsichtlich der Definition of Done verifiziert.

› Methodensteckbrief lesen

Praxisbeispiel: The same procedure as every time

In der Entwicklung steht wieder ein Statusmeeting für ein neues Produkt an. Wie so oft kommt die Anfrage aus dem Nichts und außerhalb der in den Prozessen festgelegten Qualitätsprüfungen, was die Vorbereitung erschwert. Kurzerhand stellt der Projektleiter eine lange und bunte Präsentation zusammen, um den im Lenkungsausschuss vertretenen Stakeholdern in einem kurzen Meeting den aktuellen Stand des Projekts darzustellen.

Das Ergebnis des Statusmeetings ist für alle Seiten ernüchternd – wie so oft unter diesen Vorzeichen! Es gelingt dem Projektleiter nicht, in dem vom Lenkungsausschuss auf eine halbe Stunde angesetzten Meetings und nur mit Hilfe von Folien den Stand der Entwicklung gut darzustellen. Schnell verschiebt sich der Fokus auf die offenen Punkte und die Features, die gerade nicht funktionieren.

Das sorgt sowohl beim Lenkungsausschuss als auch beim Projektleiter und seinem Team für Frustration: Die einen haben das Gefühl, dass die Projektziele in Gefahr geraten und damit auch die Bedürfnisse des Kunden nicht erfüllt werden können, während die anderen ihre geleistete Arbeit nicht gewürdigt sehen. Das Meeting war somit weder effektiv, noch brachte es das Projekt weiter, sorgte stattdessen für schlechte Stimmung und demotivierte das Projektteam (siehe auch Bild 1).

klassische Statusmeetings sorgen häufig für allgemeine Ernüchterung

Bild 1: Aufgrund des sehr unterschiedlichen Informationsstands der Teilnehmer sorgen klassische Statusmeetings häufig für allgemeine Ernüchterung

Da diese klassischen Statusmeetings nur in relativ großen zeitlichen Abständen zueinander stattfanden, kann man dem Lenkungsausschuss kaum einen Vorwurf machen, denn dadurch war er nicht eng genug dran an der Entwicklung, um zu verstehen, wie der aktuelle Stand tatsächlich zu bewerten ist, wo die Herausforderungen liegen und welche das Team bereits gemeistert hat.

Wie kann es besser gehen?

Damit der Lenkungsausschuss künftig besser informiert war, wollte das Projektteam mehr Transparenz herstellen. Dazu sollten regelmäßige Produktdemos an die Stelle der Statusmeetings treten. Denn im Mittelpunkt einer Demo steht immer das zu entwickelnde Produkt, welches Entwickler und Stakeholder dort gemeinsam unter die Lupe nehmen, um es weiter zu verbessern.

Diese partnerschaftliche und auf Augenhöhe stattfindende Herangehensweise unterscheidet sich völlig vom klassischen Statusmeeting, welches vom Projektteam meist als Überprüfung empfunden wird, die darauf abzielt, offene Punkte und Probleme zu identifizieren. Die Demos, deren Ziel die gemeinsame Verbesserung des Produkts ist, genießt demgegenüber viel mehr Akzeptanz (siehe auch Bild 2).

höhere Transparenz, die das Vertrauen der Stakeholder stärkt
Download PDFDownload PDF

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
2 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 2
Kommentare 2

Alle Kommentare (2)

Frank
Märtins
Dipl.-Inf.

Das hört sich sinnvoll an, weil der Fortschritt so deutlicher wird; Wirksamkeit werde ich mal überprüfen. Danke für die Anregung!

 

Hallo Herr Märtins, danke für Ihren Kommentar. Konnten Sie Wirksamkeit in Ihrem Umfeld schon prüfen? Wenn ja was waren die Ergebnisse?