Tja – Corona hat uns fest im Griff aber keine Sorge – ich mach nicht noch eine Sonderfolge zu Corona…In den Folgen davor sind wir ja schon ein paar Scrum-Meetings durchgegangen und so liegt es nahe in dieser Folge nun mit dem nächsten Meeting weiterzumachen – dem Meeting mit dem sich ein Sprint dem Ende nähert – Dem Review Meeting
Was ist das Review-Meeting? Im Review wird gezeigt, was im Sprint realisiert worden ist, es wird also das geplante Produkt-Inkrement demonstriert.
Nach dem Scrum-Guide ist der Zweck des Meetings, das während des Sprints realisierte Ergebnis zu überprüfen und das Product-Backlog bei Bedarf anzupassen. Es ist also nicht so zu verstehen, dass hier nur gecheckt wird, ob auch alle Userstories erledigt worden sind – der wesentliche Teil des Meetings ist die Diskussion von Ideen und Änderungen, die den Wert des Produktes weiter steigern können und diese dann ins Product Backlog aufzunehmen. Das Review-Meeting hat also nichts mit einem Projekt-Status-Meeting oder einem Abnahmeprozess zu tun. Wichtig ist es auch zu verstehen, „wessen“ Meeting das eigentlich ist: Es ist ein Meeting des Product Owners – Er lädt zum Beispiel wichtige Stakeholder ein und erklärt, welche Features oder Funktionen fertig geworden sind. Er kann auch selbst die Dinge vorführen, im allgemeinen wird das aber dem Dev.-Team überlassen. Dazu bietet es sich an, das Review – ähnlich wie das Planungsmeeting – in 2 Teile aufzuspalten: der erste Teil dient der Präsentation des Erreichten und der zweite Teil ist eine Diskussion über das Feedback, die Dinge, die sich daraus ergeben und als nächstes zu tun sind, die Überprüfung von Auslieferterminen, Erwartungen, Budget usw.
Das Ergebnis des Reviewmeetings ist daher nicht eine Liste von abgenommenen Userstories sondern ein überarbeitetes Product Backlog, in das die Erkenntnisse des beendeten Sprints eingeflossen sind.
Von dieser Beschreibung des Reviews aus dem Scrum-Guide weicht das richtige Leben – wie sollte es anders sein – mal wieder an der ein oder anderen Stelle ab und das wirkt sich meistens negativ auf den Projektverlauf aus (auch wenn man das nicht wahr haben möchte).
Daher kommen jetzt ein paar Abweichungen, vor denen ich Dich warnen möchte: Nicht weil ich es besser weiß, sondern weil diese Abweichungen Deinem Projekt schaden werden…
Abweichung Nr. 1: Es gibt gar kein Sprint-Review: Der Product Owner ist ja eng mit dem Team verbunden und kennt ja sowieso durch die Daily-Standups schon, was die Leute gemacht haben. Ein Review wäre dann ja nur Zeitverschwendung…Und was ist mit den Stakeholdern? Wie können neue Ideen entstehen, wenn man das Erreichte nicht nochmal klar vor sich sieht? Und vielleicht auch mal ausprobiert? Denke daran, dass das Reviewmeeting den Zweck hat Feedback zu bekommen und neue Userstories – also Verbesserungen – anzuregen. Ohne den offiziellen Rahmen eines Reviewmeetings findet das nicht statt und du beraubst Dich eines der wesentlichen Vorzüge von Scrum.
Abweichung Nr. 2: Das Sprint-Review als Projekt-Statusreport: wir haben geliefert: 10 Userstories mit 42 Tasks, 2 Bugfixes – prio 1, 3 Bugsfixes Prio 2 und 3 andere. Insgesamt wurden 53 Storypoints erreicht, das macht eine Steigerung von 5% gegenüber dem letzten Srint…So vorzugehen zeigt auch, dass der Sinn des Reviews und womöglich sogar der Sinn des ganzen Projektes vom Scrum-Team gar nicht verstanden wurde. Es sollte immer um Inhalte gehen und nicht um KPI‘s.
Abweichung Nr. 3: Die Powerpoint-Schlacht: Hochglanzfolien zeigen dem Management, was das Team alles Tolles erreicht hat. Nur: Hätte das Team sich nicht den halben Sprint mit der Erstellung und Abstimmung von Folien für das geneigte hochrangige Publikum aufgehalten, wäre viel mehr Nutzen für das Unternehmen möglich gewesen…Die Transparenz kommt durch die Live-Demo, nicht durch aufgehübschte Folien, die womöglich noch geschönt sind und von Problemen ablenken…Ausserdem schlafen alle ein, wenn das Reviewmeeting in einen Vortrag mit 83 Folien mutiert. Also heißt die Devise: zeigen statt erzählen!
Abweichung Nr. 4: Buchhalterei: Jeder präsentiert für sich genau die Userstories, die er umgesetzt hat. Die anderen hören gar nicht mehr zu. Es geht nur um das Abhaken der Story durch den Product Owner, nicht um eine integrierte Lösung oder ein gemeinsames Produktinkrement, die Stakeholder verstehen im schlimmsten Falle gar nicht, was das überhaupt mit ihrem Produkt zu tun hat… Wichtiger wäre es am Anfang des Meetings klar das Sprintziel herauszustellen und welchen Nutzen die Stakeholder mit den realisierten Features haben. Es geht nicht darum im Review zu beweisen, dass jeder Task umgesetzt wurde, sondern welcher Nutzen für den User erreicht wurde. Dinge, die für den Stakeholder nicht relevant sind, brauchen auch gar nicht gezeigt zu werden. Das Team sollte sowieso darauf achten, keine technischen Schulden aufzubauen oder Tests und Doku’s zu unterschlagen. Das rächt sich später und das sollte das Team auch verstanden haben.
Abweichung Nr. 5: Nebenschauplätze im Sprint. Blöd ist auch, wenn das Team Dinge macht, die gar nicht im Planungsmeeting besprochen wurden und der Product Owner dann im Reviewmeeting das erste Mal damit konfrontiert wird. Schließlich bestimmt der Product Owner ja WAS gemacht wird und das Dev.Team bestimmt WIE es gemacht wird und nicht anders herum. Wenn Du das als Scrum-Master merkst, gehe dazwischen und sorge für Transparenz: entweder der Product Owner muss involviert werden oder es laufen irgendwelche Linenmanager durch die Gegend, die in den Teams Arbeit am Product Owner vorbei verteilen. Das musst Du als Scrum Master dann unterbinden…
Abweichung Nr. 6: Das Dev-Team ist nicht anwesend: „Die anderen müssen noch ein wichtiges Update einspielen, ich bin heute alleine da“…Autsch – Im Review wird das Inspect and Adapt durchgeführt, also hier kommen die wichtigen Infos – also das Feedback – hoch und dieses Feedback muss vom Dev.-Team auch verstanden werden, damit der Sinn der Arbeit deutlich wird und die Anwendungsfälle oder die Bedienung durch die Kollegen vom Fachbereich klar wird. Nur so kann gemeinsam eine weitere Verbesserung erreicht werden. Wenn nicht alle dabei sind, fällt dieser entscheidende Punkt weg und über kurz oder lang leidet die Motivation der Dev.-Team Mitglieder und das Projekt gerät aus dem Fokus…
Abweichung Nr. 7: Keine Stakeholder anwesend: Das Review lebt vom Feedback. Wenn keiner da ist, der Feedback geben kann, gibt es keinen Fortschritt und keine kontinuierliche Verbesserung. Ausserdem kann das auch ein Gefühl von Desinteresse verursachen und wäre somit ein Demotivator für das Team.
Abweichung Nr. 8: Besprechung von nicht fertigen Stories: Unfertige Userstories haben im Review nichts zu suchen. Erstens ziehen sie das Meeting in die Länge, weil man sich um Dinge kümmert, die noch gar keinen Nutzen bringen weil sie noch gar nicht funktionieren und zweites läuft man natürlich in die Gefahr Schuldige zu suchen und darüber zu diskutieren, warum was nicht fertig geworden ist.
Abweichung Nr. 9: Der selbstsüchtige Product Owner: Der Product Owner präsentiert im Review den Stakeholdern, was ER umgesetzt oder was ER erreicht hat. Sowas kommt beim Dev.-Team nicht gut an – Es geht hier immer um eine Teamleistung – der Product Owner ist nichts ohne das Team und das Team ist nichts ohne den Product Owner. Solltest Du also Product Owner sein, denke bitte daran, hier nicht zu übertreiben…
Abweichung Nr. 10: Der feedbackresistente Product Owner: Wenn Du als Product Owner der Meinung bist, Du weißt was für die Stakeholder oder Kunden besser ist als sie selbst, dann wird es schwierig. Auch hier gilt: es geht immer um die Sache und nicht um Deine persönliche Profilierungen. Keine Angst – die kommt automatisch, wenn du deine Stakeholder einbeziehst.
Abweichung Nr. 11: Schwindeln….ich will es nicht betrügen nennen, aber wenn das Dev.-Team Dinge vorführt, die eigentlich noch voller Bugs stecken und somit die DoD nicht erfüllen, macht man sich was vor. Alle müssen ehrlich miteinander umgehen – sonst seid ihr nicht transparent und es wird was verheimlicht…und das fällt euch später auf die Füße (alte Regel!)
Abweichung Nr. 12: Verfolgen eines Projektplans…Im Review wird heimlich ein schon vorher verabschiedeter Projektplan umgesetzt und die erreichten Arbeitspakete abgehakt. Es wird nicht über den aktuellen Status des Projekts oder des Produkts gesprochen und es wird kein Feedback eingeholt und vor allem, es wird nichts am Backlog geändert um den Ergebnissen der Diskussion Rechnung zu tragen… dann sind wie wieder im Wasserfall gelandet…und das Team wird keine Verbesserung erreichen können…
Abweichung Nr. 13: keine Kunden anwesend: Das wird wahrscheinlich nicht immer die Regel sein können, aber denke mal darüber nach, auch zahlende Kunden für dein Produkt zum Review einzuladen um das WIRKLICHE Feedback einzuholen. Das bringt mehr als immer nur dem eigenen Fachbereich zuzuhören, der oft genug selbst in einem Elfenbeinturm sitzt und gar nicht weiß, worauf es dem zahlenden Kunden wirklich ankommt.
Abweichung Nr. 14: Alles immer neu erklären…Wenn die Stakeholder immer wieder wechseln und immer wieder neue Leute auftauchen, denen man in jedem Review das Projekt erstmal von Grund auf erklären muss, dann hält das auf der einen Seite nur auf, auf der anderen Seite ist es nicht möglich ein fundiertes Feedback zu erhalten, was essentiell für das Review-meeting ist. Hier wäre wieder ein Ansatzpunkt für Dich als Product Owner oder Scrum Master in einer Retro drüber zu sprechen und dafür zu sorgen, dass Stakeholder auch für längere Zeit oder über das ganze Projekt eine Verantwortung dafür übernehmen und sich ihrer Bedeutung für das Projekt auch bewusst werden.
Abweichung Nr. 15: Passive Stakeholder. Wenn die Stakeholder passiv und unengagiert sind, ist nur noch nicht das Feuer in ihnen entfacht. Du kannst zum Beispiel als Scrum Master dann dafür sogen, dass die Stakeholder selbst das Review moderieren oder organisiere das Review als Messe mit verschiedenen Ständen, in denen die neuen Funktionen gezeigt werden. Natürlich nicht immer aber es kann eine gute Initialzündung sein, um die Stakeholder zu aktivieren.
Abweichung Nr. 16: Review als Tachometer: Wenn der einzige Zweck des Review ist, zu zählen wieviele Userstories oder Backlogitems umgesetzt worden ist um letztlich die Velocity des Teams zu ermitteln, dann läuft auch was falsch.. Es geht nicht um KPI-Ermittlung – es geht um Feedback und Optimierung des Produkts…
Da komme ich doch gleich nochmal zur Velocity – was ist das eigentlich: also die Velocity ist die Summe aller Storypoints, die das Team wirklich erreicht hat (also gezählt werden nur die Stories, die „done“ sind, angefangene und nicht abgeschlossene Stories werden nicht gezählt!). Die Velocity wird oft als Maß für die Teamperformance verwendet und es wird viel zu viel Bedeutung darein gelegt.
Die Performance eines Teams misst sich nicht in der Velocity, sondern am Wert, den das Team für das Unternehmen schafft, in dem es Dinge umsetzt, die nützlich sind. Die Velocity ist nur eine Hilfsgröße um es dem Team im Planungsmeeting leichter zu machen, den Umfang des Sprint-Backlogs möglichst realistisch abzuschätzen. Dabei ist es natürlich sinnvoll zu wissen, was man als Team in der Vergangenheit so geschafft hat…Für mehr sollte die Velocity nicht verwendet werden – erst recht nicht dazu, mehrere Team miteinander zu vergleichen. Jedes Team entwickelt eine eigene Metrik im Umgang mit den Storypoints, daher macht es gar keinen Sinn die Teams zu höheren Zahlen zu treiben. Das fördert höchstens Output, also die Produktion von Fehlern und Waste und hat nichts mit Motivation zu tun…
Soweit dazu…
Aber -Es ist wie überall – und daran möchte ich nochmal erinnern: Gehe nicht zu dogmatisch vor! Wenn gute Gründe vorliegen, mal von den eigentlichen Idealen des Scrum abzuweichen, dann ist das nicht verboten. Du musst nur wissen, dass das dann tendenziell dazu führt, dass ihr weniger effizient im Projekt arbeitet, als es möglich gewesen wäre…
so
Nachdem ich jetzt die ganze Zeit mehr oder weniger darüber geredet habe, was man alles NICHT machen soll, hier noch ein paar Fragen, die Du stellen kannst, um ein geeignetes Feedback von Deinen Stakeholdern zu bekommen: Die Teilnehmer können die Antwort jeweils auf ein Post-It schreiben und ihr könnt das dann im Anschluss auswerten…
Hilfreich ist es zum Beispiel nach Skalen zu fragen – also sowas wie: Wie wahrscheinlich ist es, dass Du das Produkt einem Freund oder Kollegen empfehlen würdest (auf einer Skale von 0 = unwahrscheinlich bis 10= auf jeden Fall)
oder Wie perfekt ist das Produkt auf einer Skala von 0 bis 10 – wenn Du keine 10 gibst, was fehlt dem Produkt um eine 10 zu erreichen?
Eine andere Frage wäre: Wie würdest Du das Produkt benutzen? Würdest Du das Produkt selbst- persönlich auch benutzen? – Warum? oder Warum nicht?
Oder als Demo: bitte benutze das Produkt für die nächsten 5 Minuten und erzähle uns alles was dir dazu einfällt.-
Oder eine Story: Erzähle uns bitte mal, wie du das Produkt zu hause oder bei der Arbeit benutzen würdest.
Oder das „Bauchgefühl“ – das finde ich auch immer sehr gut: Wenn Du nur ein Wort hättest: Was fällt Dir zu dem Produkt ein?
oder – Dinge wie: wenn dieses Produkt einen Geruch hätte, welcher Geruch fällt dir dazu ein, oder wenn dieses Produkt ein Auto – oder ein Tier wäre: welches fällt Dir dazu ein? (hier kommt gut raus, ob es zum Beispiel ein „Ferrari“ oder eine lahme Ente ist oder wie auch immer…
Konkret kannst Du auch fragen: Wenn Du eine Sache hinzufügen könntest, was würde das sein?
oder – wenn Du eine Sache weglassen müsstest, was würde das sein?
Oder natürlich die starken Gefühle wie Liebe und Hass: was liebst Du am meinsten an dem Produkt – oder was kannst DU am wenigsten leiden?
Du kannst das Ganze natürlich auch von der anderen Seite aufziehen…wie können wir das Produkt richtig schlecht machen, sozusagen, was wäre der absolute Albtraum von einem Produkt? – um hinterher die Sichtweise umzudrehen und darüber nachzudenken, wie man sowas vermeiden kann…
So Ich denke, du hast nun einen Überblick davon, worum es in einem Sprint-Review eigentlich geht.
Ich danke Dir fürs zuhören und würde mich über eine Bewertung in iTunes sehr freuen. Bitte Teile auch den Link zum agilophil-daily podcast, so das wir eine immer größere Gruppe von agilophilen Menschen werden…sharing is caring…
NEU: Tschüß – dein agilophiler Frank