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

Bild 2: Durch regelmäßige Demos entsteht höhere Transparenz, die das Vertrauen der Stakeholder stärkt

7 einfache Regeln

Für die Demos (man könnte sie auch "proaktives Update zum aktuellen Stand des Produkts" nennen) legte das Team gemeinsam folgende Regeln fest, die sich in der Praxis auch bewährten:

  1. Turnus: alle vier Wochen bis maximal drei Monate, je nach Umfang des Projekts. Die Termine plant und kommuniziert das Team frühzeitig; Verschieben ist nur in Ausnahmefällen erlaubt
  2. Teilnehmer: Projektleiter, das gesamte Team sowie die involvierten Stakeholder die Interesse am Projekt/Produkt haben
  3. Dauer: höchstens 90 Minuten (optimal ist eine Stunde)
  4. Ort: Die Demo findet im Teamraum oder Labor statt
  5. Art der Präsentation: PowerPoint-Präsentationen sind auf ein absolutes Minimum zu beschränken (z.B. zur kurzen Vorstellung und Wertschätzung des Teams) und dienen nicht der Beschreibung des Produkts
  6. Gegenstand der Demo: Die Demo wird am realen, funktionsfähigen Produkt durchgeführt. Dies kann z.B. ein Teil einer Software, eine Prototypen-Leiterplatte, der 3D-Print eines Gehäuses oder ein handgezeichnetes Poster für eine Werbekampagne sein; nur fehlerfreie und auch getestete Produktteile dürfen gezeigt werden
  7. Beteiligung der Stakeholder: Am Ende geben die Stakeholder Feedback zum Produkt, welches das Projektteam im Anschluss bewertet und gegebenenfalls umsetzt

Wichtig ist es, die Regeln für solche Demos frühzeitig gemeinsam zu erarbeiten und dann auch konsequent einzuhalten. Nur so bildet sich im Team das notwendige Commitment, um die Demo nachhaltig zu etablieren.

Das Einbinden der Stakeholder

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 2
Kommentare 2

Alle Kommentare

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?
Alle anzeigen