Scrum-Master.de

Am Ende jedes Sprints präsentiert das Team dem Product Owner und allen interessierten Stakeholders das Ergebnis seiner Arbeit live am System und sammelt Feedback (Meinungen, Verbesserungsvorschläge, Lob und Kritik) ein.

Ablauf des Sprint Review Meeting

• Time-boxed (4 h)
• Maximal eine Stunde Vorbereitungszeit pro Person
• Das Team selbst – nicht irgendein übergeordneter Manager – zeigt dem Product Owner und anderen interessierten Personen live am funktionierenden System, was es innerhalb des Sprints erreicht hat.
• Wichtig: keine Dummies, kein Powerpoint! Nur fertige Produktfunktionalität (Increment of Potentially Shippable Functionality) darf vorgeführt werden.
• Feedback seitens Product Owner, Stakeholders u.a. Anwesenden ist erwünscht und fließt in die weitere Arbeit ein.
• Auf Basis des Gezeigten entscheidet später der Product Owner, ob das Inkrement produktiv gesetzt oder weiter entwickelt werden soll. Diese Möglichkeit hat er nach jedem Sprint. So ist gewährleistet, daß in sich abgeschlossene funktionale Bausteine eines Gesamtsystems möglichst früh einen Nutzen und somit einen Return on Investment - Manager lieben das, und zu Recht - erzeugen.

Hinweise

• Ort der Veranstaltung kann durchaus ein Entwicklerbüro sein. Team Members sollen vom Fachbereich als Menschen, nicht als Ressourcen wahrgenommen werden. Dazu gehört auch, Menschen in ihrer Umgebung zu erleben. Im Büro hängen vielleicht Bilder der Familie, Cartoons, Zeitungsausschnitte, Poster usw. Man kann das Team in seiner Umgebung, dem "eigenen Revier" erleben. Das ist völlig anders, als Menschen in einen sterilen Konferenzraum zu zitieren.
• Manager reagieren auf die Ankündigung, es werde in einem Meeting Software live gezeigt, manchmal ablehnend ("Für so etwas habe ich keine Zeit."). Auch unterhalten sie sich i.d.R. lieber mit einem Team- oder Abteilungsleiter als mit einem Entwickler oder Tester. Aber genau diese (auf Gegenseitigkeit beruhende) Abgrenzung der Projektbeteiligten voneinander - man könnte beinahe von Kastenwesen sprechen - erzeugt die allseits bekannten Effekte und Probleme in Projekten, welche wir immer zu vermeiden suchen und uns wundern, daß es nicht klappt. Wenn Menschen nicht wenigstens ab und zu direkt miteinander sondern über "Delegierte" oder nur per E-Mail kommunizieren, wie soll dann jemals ein Entwickler ein fachliches Problem verstehen und lösen können? Wie sollen ein Fachbereichskollege oder sein übergeordneter Manager vom Hörensagen verstehen, welche technischen Grenzen ein System hat bzw. welche nicht erkannten Möglichkeiten sich bieten, etwas anders oder besser zu machen?
• Warum wird überhaupt Software live vorgeführt, bevor das Projekt vollständig abgeschlossen ist? Dafür gibt es viele Gründe. U.a. kann man besser über etwas reden, das man sehen und anfassen kann als über Präsentationsfolien und Fachkonzepte. Entwicklungsfortschritt wird greifbar, Fehlentwicklungen erkennbar. Schlußendlich ist es auch einfach notwendig, wirklich zu sehen, was ein Projektteam in einem Zeitabschnitt geleistet hat. Eine direktere und bessere Möglichkeit des Projekt-Controllings hat ein Auftraggeber nicht. Aus der ansonsten gehörten Aussage eines Projektleiters, "Wir sind im Plan.", kann er sich keine konkrete Vorstellung machen und muß darauf vertrauen, daß die Aussage wahr ist. Das nennt man dann wohl "die Katze im Sack kaufen", und das tut kein Kunde bzw. Manager gern. Wieso sich also diese Kontrollmöglichkeit entgehen lassen?