Remote Sprint Review in Large-Scale Scrum (LeSS)

Gastbeitrag von | 10.06.2021

Die Einbindung von Anwendern und Kunden in die Produktentwicklung ist eine zentrale Säule der agilen Bewegung. Zwei der 4 agilen Werte besagen “Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge” und “Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung”. In Scrum, einem der beliebtesten agilen Frameworks für die Produktentwicklung, ist das Sprint Review das einzige “offizielle” Ereignis, bei dem Entwickler und Anwender/Kunden miteinander interagieren und zusammenarbeiten. Dieser Artikel gibt einen Überblick über den Zweck des Sprint Reviews in Scrum und beschreibt ein reales Beispiel, wie ein modifiziertes Sprint Review in Large-Scale Scrum (LeSS) mit mehreren verteilten Teams gestaltet werden kann.

Der Zweck des Sprint Reviews

Das Herzstück von Scrum ist die empirische Prozesskontrolle. Durch sie unterscheidet sich Scrum von anderen agilen Frameworks. Anstelle eines detailliert definierten Prozesses verwendet Scrum kurze Zyklen zur Erstellung kleiner auslieferbarer Produktteile und erlaubt darüber hinaus, sowohl das Produkt als auch den Prozess nach jedem Zyklus zu inspizieren und beides bei Bedarf anzupassen. Während das Sprint Review die kontinuierliche Überprüfung und Anpassung des Produkts ermöglicht, tut die Sprint Retrospektive dies für den Prozess.

Im Sprint Review inspizieren die Benutzer/Kunden und andere Stakeholder gemeinsam mit dem Product Owner und dem/den Team(s) das Product Increment und passen bei Bedarf das Product Backlog an. Dies geschieht, indem jeder die Möglichkeit hat, neue Elemente praktisch zu erforschen, und darüber zu diskutieren, was auf dem Markt und bei den Benutzern vor sich geht.

Das Sprint Review ist der ideale Zeitpunkt, um ein gemeinsames Verständnis der Teilnehmer zu schaffen. Es gilt zu bekräftigen, ob das Product Backlog weiterhin die Bedürfnisse der Benutzer/Kunden und des Marktes widerspiegelt oder Änderungen zur Wertmaximierung vorzunehmen sind.

Transparenz ist neben der Überprüfung und Anpassung der Schlüssel für die empirische Prozesssteuerung, und daher verfehlt auch die Bezeichnung “Sprint Demo” mit einer Fokussierung auf eine einseitige Präsentation ohne praktische Anwendung des Produkts den Sinn des Sprint Reviews in Scrum oder LeSS.

Sprint Review in Scrum

In Bezug auf den Inhalt des Sprint Reviews war der Scrum Guide 2017 ziemlich explizit. Er enthielt folgende Ausführungen:

  • Zu den Teilnehmern gehören das Scrum-Team und wichtige Stakeholder, die vom Product Owner eingeladen werden;
  • Der Product Owner erklärt, welche Product Backlog Items erledigt und welche nicht erledigt wurden;
  • Das Entwicklungsteam bespricht, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden;
  • Das Entwicklungsteam demonstriert die Arbeit, die es erledigt hat, und beantwortet Fragen zum Inkrement;
  • Der Product Owner bespricht den Stand des Product Backlogs. Er projiziert (falls nötig) wahrscheinliche Ziel- und Liefertermine basierend auf dem bisherigen Fortschritt.
  • Die gesamte Gruppe arbeitet gemeinsam daran, was als Nächstes zu tun ist, so dass das Sprint Review wertvollen Input für die nachfolgende Sprintplanung liefert;
  • Die Überprüfung, wie sich der Markt oder der potenzielle Einsatz des Produkts verändert haben könnte, was als nächstes zu tun ist; und,
  • die Überprüfung des Zeitplans, des Budgets, der potenziellen Fähigkeiten und des Marktes für die nächsten erwarteten Funktions- oder Fähigkeitsversionen des Produkts sind durchzuführen.

Das Ergebnis des Sprint Reviews ist ein überarbeitetes Product Backlog, das die wahrscheinlichen Product Backlog Items für den nächsten Sprint definiert. Das Product Backlog kann auch insgesamt angepasst werden, um neuen Möglichkeiten gerecht zu werden.

Der Scrum Guide 2020 ist im Allgemeinen und auch im Speziellen deutlich kürzer und weniger präskriptiv. In Bezug auf das Sprint Review heißt es:

Während des Events überprüfen das Scrum Team und die Stakeholder, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat. Basierend auf diesen Informationen erarbeiten die Teilnehmer gemeinsam, was als nächstes zu tun ist. Das Product Backlog kann auch angepasst werden, um neuen Möglichkeiten gerecht zu werden. Das Sprint Review ist eine Arbeitssitzung und das Scrum Team sollte es vermeiden, es auf eine Präsentation zu beschränken.

Sprint Review in LeSS

LeSS ist (wie Scrum) ein “gerade noch hinreichendes” Framework für hochwirksame Agilität. Es befasst sich mit der Frage, wie sich Scrum mit vielen Teams, die gemeinsam an einem Produkt arbeiten, anwenden lässt. Mehr über das LeSS-Framework finden Sie unter https://less.works.

In LeSS gibt es eine Regel bezüglich des Sprint Reviews:

  • Es gibt ein Product Sprint Review; es ist für alle Teams gleich. Stellen Sie sicher, dass geeignete Stakeholder teilnehmen, um die Informationen beizusteuern, die für eine effektive Überprüfung und Anpassung benötigt werden.

Darüber hinaus gibt es zwei Guides und einige Experimente, die sich auf das Sprint Review beziehen:

Guide: Passen Sie das Produkt früh und oft an

Dieser Ratgeber schlägt vor, die Zyklen für die Erstellung neuer Product Slices so kurz wie möglich (und sinnvoll) zu halten, möglichst viele Informationen über den Kundenmarkt auszutauschen und gemeinsam zu besprechen, was als nächstes zu tun ist, um das Lernen zu maximieren.

Guide: Review Bazaar

Dieser Leitfaden schlägt vor, den ersten Teil des Sprint Reviews wie eine Wissenschaftsmesse durchzuführen: Ein großer Raum mit mehreren Bereichen, die jeweils mit Teamvertretern besetzt sind, in denen die entwickelten Elemente gemeinsam mit Benutzern, Teams usw. erkundet und diskutiert werden. Aber Vorsicht! Der Review Bazaar ist nur der erste Teil des Sprint Reviews. Der zweite Teil besteht aus kritischen Diskussionen, die für die Reflexion und die Entscheidung über die nächsten Schritte notwendig sind.

Der Guide gibt einige klare Tipps, wie Sie den Review Bazaar in einer Reihe von Schritten organisieren können:

  1. Bereiten Sie verschiedene Bereiche für die Erkundung unterschiedlicher Gruppen von Elementen vor. Beziehen Sie Geräte ein, auf denen das Produkt läuft. Teammitglieder stehen in jedem Bereich für Fragen und Diskussionen mit Benutzern, Kollegen aus anderen Teams und Stakeholdern zur Verfügung. Durch die Fragen und Diskussionen lernen alle gemeinsam. Stellen Sie Feedback-Karten aus Papier zur Verfügung, um interessante Aspekte und Fragen festzuhalten.
  2. Laden Sie Personen – auch andere Teammitglieder – explizit ein, jeden Bereich zu besuchen.
  3. Nutzen Sie einen Kurzzeit-Timer (z.B. 15 Minuten) während der Erkundung. Der Timer schafft eine Kadenz, in der man zu einem anderen Bereich weitergeht.
  4. Während die Teilnehmer die Gegenstände mit den Händen erkunden und gemeinsam diskutieren, halten Sie wichtige Aspekte auf den Karten fest.
  5. Am Ende des kurzen Zyklus laden Sie die Teilnehmer ein, einen anderen Bereich zu erkunden oder für einen weiteren Zyklus zu verweilen. Diese Mini-Zyklen tragen zu einer breiteren und vielfältigeren Erkundung aller Items bei.

Nach dem Review Bazaar folgen die wichtigsten Schritte des Meetings:

  1. Die Teilnehmer sortieren ihre Feedback- und Fragekarten so, dass der Product Owner die wichtigen Karten zuerst sieht.
  2. Der Product Owner leitet die Diskussion über den Markt und die Kunden, das anstehende Geschäft, das Marktfeedback zum Produkt und ganz allgemein über das, was draußen passiert. Dafür verwendet der Product Owner die Feedback-Karten.
  3. Am wichtigsten für das gesamte Review ist eine Diskussion – und vielleicht eine Entscheidung – über die Richtung des nächsten Sprints.

Das zweite LeSS-Buch bietet einige Experimente in Bezug auf das Sprint Review, wie z.B. die Verwendung von Videositzungen, einschließlich Diverge-Converge-Zyklen in großen Videomeetings, oder das Experimentieren mit Multisite-Scrum-Meeting-Formaten und -Technologien. In diesem Artikel lege ich den Fokus auf ein ausführliches Beispiel des Experiments “Remote Sprint Review” und kombiniere es mit vielen Ideen aus anderen Experimenten.

Remote Sprint Review in Aktion

Eine LeSS-Regel, die sich auf die LeSS-Struktur bezieht, besagt, dass “jedes Team (1) selbstverwaltend, (2) funktionsübergreifend, (3) co-located und (4) langlebig ist”.

In der heutigen Zeit kann fast kein Team co-located arbeiten, da jedes Mitglied gezwungen ist, (die meiste Zeit) von zu Hause aus zu arbeiten. Daher experimentieren viele Teams mit verschiedenen Möglichkeiten, wie man LeSS-Veranstaltungen aus der Ferne durchführen kann. Hier ist ein Ansatz für einen Review Bazaar, den wir bei einem meiner Kunden, der Yello Strom AG, durchgeführt haben. In der folgenden Beschreibung werde ich die Schritte, die wir verwendet haben, mit Ihnen teilen, und im Anschluss daran erläutern, was meiner Meinung nach noch verbessert werden könnte.

Der organisatorische Kontext

Ich möchte mit einer wichtigen Bemerkung zum organisatorischen Aufbau beginnen: Wir haben bei diesem Kunden nicht mit LeSS gearbeitet, da sich Ziel des Bereichs vom Systemoptimierungsziel in LeSS unterschied. Trotzdem war unser Sprint Review mit mehreren Teams sehr ähnlich zu dem, wie ich ein Sprint Review in LeSS durchführen würde.

Um die Art und Weise des Sprint Reviews genau zu beschreiben, möchte ich Ihnen eine kurze Einführung in den organisatorischen Aufbau geben. Bedenken Sie bitte, dass ich diesen Aufbau für die Entwicklung eines Produkts mit mehreren Teams nicht empfehlen würde. Am Ende des Artikels beschreibe ich, wie Sie ein Sprint Review in LeSS durchführen könnten.

Der Kunde, die Yello Strom AG, ist ein deutscher Strom- und Gasversorger, ein Tochterunternehmen der EnBW. Der Bereich, mit dem ich bei der Yello Strom AG gearbeitet habe, war für Innovation und die Entdeckung neuer Geschäftsmodelle zuständig. Er bestand aus 4 Teams, die sich jeweils auf ein konkretes Produkt konzentrierten.

Es gab ein Team, das eine revolutionäre App entwickelte, die es den Menschen ermöglicht, den Unterschied zwischen dem Fahren eines Autos mit Verbrennungsmotor und einem Elektroauto zu verstehen. Diese App sollte in der Lage sein, ein Elektroauto zu empfehlen, das u.a. zu den persönlichen Bedürfnissen passt, die Anzahl und Art der Fahrten pro Woche und die Lademöglichkeiten zuhause berücksichtigt.

Ein anderes Team arbeitete an einer nutzergenerierten Plattform, die es Menschen ermöglichen sollte, persönliche Bewertungen zu elektronischen Produkten zu teilen. Ein drittes Team erstellte ein neues Strompreismodell für Menschen mit Elektroautos. Und das vierte Team schrieb und erstellte Inhalte für verschiedene (Medien-)Kanäle, wie Blogs, YouTube-Videos, Instagram oder Twitter-Posts.

Jedes Team hatte einen Product Owner und die Abteilung hatte einen sogenannten Business Owner. Jedes Team hatte sein eigenes Product Backlog, einige nutzen 2-Wochen-Sprints, andere 1-Wochen-Design-Sprints. Alle 2 Wochen führten wir dieses gemeinsame Sprint Review durch.

Sprint Review Setup

Das Tool, das wir als Gruppe zur Kommunikation nutzten, war Microsoft Teams, das zu diesem Zeitpunkt leider noch keine Breakout-Räume unterstützte, so dass wir in dieser Hinsicht einige Workarounds schaffen mussten.

Da die meiste Interaktion zwischen den Teilnehmern sichtbar stattfinden sollte, nutzten wir Miro als “endloses” Whiteboard. Hier wurde die Agenda der Veranstaltung geteilt, hier bereiteten die Teams Screenshots der Produktteile vor, die sie besprechen wollten, um den Teilnehmern die Möglichkeit zu geben, Kommentare und Feedback hinzuzufügen, und hier fand auch die sonstige Interaktion zwischen den Teilnehmern statt.

Einer der wichtigsten Teile eines Remote Sprint Reviews ist die Vorbereitung. Die Teammitglieder sollten das Sprint Review immer gut vorbereiten, um das Beste aus diesem Inspektions- und Anpassungs-Event herauszuholen. Aber, wie wir sehen werden, muss für ein Remote-Event nicht nur das Produkt (Inkrement) vorbereitet werden, sondern auch Möglichkeiten, wie die Teilnehmer effektiv Feedback austauschen können. Unsere Teams mussten im Durchschnitt etwa eine Stunde pro Sprint einplanen, um das Miro Board für das Sprint Review vorzubereiten, damit diese Besprechung effektiv ablaufen konnte. Darüber hinaus bereitete auch der PO in der Regel relevante Informationen vor, um sie mit den Teams und den anderen Teilnehmern zu teilen.

Hier sehen Sie, wie das Gesamtboard für eines unserer Sprint Reviews aussah:

Miro Board with a Sprint Review
Weiter unten finden Sie Details des Boards.

Agenda

Der nächste Screenshot zeigt eine typische Sprint Review Agenda.

Wir hatten eine Zeitbeschränkung von nicht mehr als 2 Stunden, was in den meisten Fällen funktionierte, auch wenn ich mir manchmal wünschte, wir hätten etwas mehr Zeit gehabt.

Unsere Agenda bestand aus 8 Blöcken:

  1. Eine kurze Begrüßung und Check-in,
  2. 10 min für Firmen- und Abteilungs-Updates,
  3. ein kurzes Status-Update zum Stand der Teams,
  4. das Pitching der Teams,
  5. der tatsächlich Review Bazaar,
  6. die Sammlung und Zusammenfassung des Feedbacks,
  7. die Besprechung der nächsten Schritte und
  8. eine kurze Feedbackrunde zum Sprint Review selbst.

 

Agenda for Sprint Review

Üblicherweise begannen wir unsere Veranstaltung damit, die Schritte, die während des Sprint-Reviews durchgeführt wurden, separat zu erwähnen und Änderungen am Ablauf einzuführen, sofern diese im vorherigen Event oder der Sprint Retrospektive beschlossen wurden. Wir stellten fest, dass Teilnehmer, die zum ersten Mal an dieser Veranstaltung partizipierten, im Vorfeld von einer individuellen Einführung in den Ablauf der Veranstaltung profitierten. So konnten wir den ersten Punkt der Tagesordnung kurz halten. Dies ist auch ein guter Zeitpunkt, um ein kurzes Check-In zu machen, indem die Teilnehmer bspw. ein Wort in das Chat-Feld tippten, ein Giphy oder vielleicht ein Bild in einem Bereich des Whiteboards posteten.

Es folgten ein paar Worte des Geschäftsinhabers, bei dem er wichtige Firmen-Updates und Abteilungs-Updates ankündigen oder neue Mitarbeiter vorstellen konnte.

Team Status und Session Pitching

Der dritte Punkt auf unserer Agenda war ein kurzer Statusüberblick, der widerspiegelte, wo sich die Teams auf ihrer jeweiligen Reise befanden. Wie bereits erwähnt, hatten wir 4 Teams, die an 4 verschiedenen Produkten arbeiteten, und dies war die Gelegenheit für jedes Team, verbal und visuell mitzuteilen, was gerade passierte: Updates in Bezug auf Nutzungszahlen, Markt-Updates, Hindernisse und das weitere Vorgehen. Meistens wurde dies von den Team-POs durchgeführt und dauerte nicht länger als 5 Minuten pro Team.

Wie Sie auf dem Screenshot unten sehen können, haben wir dafür eine Tabelle auf dem Board mit 4 Spalten erstellt (Hindernisse & Hilfsanfragen, Erfolge, Danke, Nächste Schritte).

Team Status and Session Pitching

Danach (oder manchmal während der Updates) gab jedes Team eine kurze Einführung zu den Produktinkrementen, die zur Erkundung im Review Bazaar vorbereitet worden waren.

Jedes Team, das etwas Neues mitzuteilen hatte, bereitete einen oder mehrere Abschnitte auf dem Board mit Anweisungen vor, wo die Produktinkremente zu finden waren und wie sie getestet werden konnten. Manchmal wurden die Anweisungen durch Schlüsselfragen für das Feedback ergänzt. Meistens fügten die Teams Screenshots von den neuen oder aktualisierten Teilen des Produkts (Website oder App) hinzu. Dies machte es für die Teilnehmer sehr einfach, das Feedback mit einem bestimmten Bereich des Produkts zu verknüpfen. Für allgemeine Anmerkungen und Feedback erstellte jedes Team außerdem einen Abschnitt mit 4 Quadranten (Was hat funktioniert? / Was hat mich verwirrt? / Was hat nicht funktioniert? / Irgendwelche neuen Ideen?).

Der Review Bazaar

Nach etwa 45 Minuten begann der spannendste Teil des Reviews. Die Teilnehmer begannen, sich auf dem Miro Board zu bewegen und die Angebote zu erkunden. Wie bereits erwähnt, waren die Angebote sehr vielfältig und das Review wurde so gestaltet, dass die Teilnehmer auswählen konnten, welche Teile für sie am interessantesten waren und an welchen Stellen sie den größten Beitrag leisten konnten, indem sie das das Gesehene bewerteten und Feedback gaben.

Das Content-Team teilte in der Regel Artikel oder YouTube-Videos, die im Sprint erstellt und veröffentlicht wurden. Neben dem Link zum eigentlichen Artikel fügte das Team einen Screenshot und einen Feedback-Quadranten hinzu (siehe Screenshot unten).

Asking for Feedback

In anderen Fällen fügten die Teams einen Link zu einer neuen Funktionalität auf einer Webseite oder einer ganz neuen Landing Page hinzu. Dies konnte entweder ein Link zum Live-System oder zu einer anderen (Staging-)Umgebung sein, und allgemeine Anweisungen für den Zugriff wurden ergänzt.

General Instructions

Wie bereits erwähnt, bereitete das Team für das Feedback in der Regel einen Bereich mit Screenshots der neuen Funktionalität oder eine Webseite vor und die Teilnehmer fügten Post-it-Notizen mit Kommentaren direkt neben den Bereichen hinzu. Zusätzlich dazu hatte jedes Board einen Feedback-Quadranten für allgemeines Feedback.

General Feedback

In einigen Fällen handelte es sich um eine neue Funktionalität in einer mobilen App, die zur Überprüfung zur Verfügung stand. Hier bereiteten die Teams in der Regel eine detailliertere Beschreibung vor, wie die App von einem Testserver aus zu installieren war, manchmal durch das Posten eines Links zu einem Bildschirmausschnitt, der eine Schritt-für-Schritt-Anleitung zur Installation enthielt. Außerdem gab es einen Link zu einem MS Teams-Kanal oder einem Teammitglied in Slack, das die Teilnehmer bei Problemen mit der Installation der App unterstützen konnte. Auch hier stellte das Team die relevanten Screenshots aus der App auf einem Frame in Miro zur Verfügung, damit die Teilnehmer Post-its direkt zu den Bereichen schreiben konnten, zu denen sie Feedback hatten. Darüber hinaus gab es einen Feedback-Quadranten für allgemeineres Feedback.

Providing feedback at relevant screenhots

In anderen Fällen gab es nur Mockups, Wireframes, Scribbles oder sogar Datenblätter, an denen das Team im vorherigen Sprint gearbeitet hatte. Auch hier gaben sie klare Anweisungen, welche Art von Feedback sie benötigten.

Asking Questions

In einigen Fällen bereiteten die Teams sogar Kundeninterviews für das Sprint Review vor. Sie baten die Teilnehmer, ihren Namen in einen Timebox-Slot zu schreiben, und ein Teammitglied, das darin geübt war, Kundeninterviews zu führen, ließ einen oder mehrere Teilnehmer die neue Funktionalität erleben und Fragen beantworten.

Feedback Review und Backlog Anpassung

Der nächste Schritt war das Review und die Diskussion der Teilnehmer-Feedbacks. Dazu setzte sich jedes Team mit seinem Product Owner in ihrem MS Teams-Kanal zusammen und überprüfte die Post-its und diskutierte das schriftliche Feedback sowie das, was sie während der Interviews beobachtet hatten. Dies führte in der Regel dazu, dass neue PBIs erstellt und im nächsten Product Backlog Refinement besprochen, sowie PBIs aktualisiert oder im Product Backlog neu geordnet wurden.

Sprint Review Feedback

Der letzte Schritt unseres Sprint Reviews war ein kurzes Zeitfenster zur Rückschau auf den Sprint Review. Die Teilnehmer hatten die Möglichkeit, Feedback und Ideen zur Verbesserung des Sprint Reviews zu hinterlassen. Um dies zu ermöglichen, nutzten wir einen anderen Bereich des Boards und die bekannten vier Quadranten.

How to improve the Sprint Review

Vorschläge zur Verbesserung

Wie bereits erwähnt, handelt es sich hier nicht um ein typisches LeSS Sprint Review, obwohl der verwendete Ablauf sehr ähnlich sein könnte. Wo liegen die Unterschiede?

Wie unterscheidet sich LeSS vom beschriebenen Ansatz?

Large-Scale Scrum (LeSS) bietet durch sein Regeln und Prinzipien ein Organisationsdesign, das auf Anpassungsfähigkeit bei minimalen Kosten und Kundennutzen optimiert ist. In LeSS gibt keine “Team Product Owner” und keine “Team Product Backlogs”. Um lokale Optimierung durch Effizienzsteigerung auf Teamebene zu vermeiden, gibt es ein gemeinsames Product Backlog. Das sorgt dafür, dass die Optimierung auf Systemebene stattfindet. In der Regel ist dies am sinnvollsten, wenn mehrere Teams an einem Produkt arbeiten, was eine klare Notwendigkeit schafft, dass alle Teams gemeinsam die Entwicklung des Bereichs des Produkts unterstützen, der am kritischsten für die bestmögliche Kundenwirkung ist. Und selbst in einer Situation, in der mehrere Teams parallel an mehreren Produkten arbeiten, bevorzugt LeSS die Arbeit mit einem Product Backlog (und mit einem Product Owner, der dieses Product Backlog pflegt) und breiteren Produktdefinitionen, da sie

  • zu einer besseren Übersicht über die Entwicklung und das Produkt führen,
  • Abhängigkeiten durch Feature-Teams vermeiden,
  • gemeinsames Denken mit dem Kunden fördern, in dem sie mehr Fokus auf die tatsächliche Probleme und die Auswirkungen als auf die gewünschten Anforderungen legen,
  • die Entwicklung doppelter Funktionalität vermeiden und
  • einfachere Organisationen schaffen.

Solange es also eine gemeinsame (Gesamtprodukt-)Vision gibt, die mehrere Produkte, die selben Kunden oder die selben Märkte umfassen, und das gleiche Domänenwissen relevant ist, spricht vieles dafür, die Produktdefinition auf mehrere kleinere Produkte auszuweiten.

In unserem Fall erforschte die Abteilung mehrere innovative Produkte mit mehreren Teams, so dass die Arbeit mit einem einzigen Product Backlog viel Sinn ergeben hätte, insbesondere weil die Erforschung und Lieferung der Produkte extrem schnell und anpassungsfähig gewesen wäre. Es hätte der Organisation erlaubt, die Investitionen in das erfolgreichere Produkt “on the fly” zu erhöhen, anstatt mit einer definierten Gruppe von Leuten eine definierte Zeit an mehreren Produkten arbeiten, nur um dann ab einem bestimmten Zeitpunkt einige Produkte wegzuwerfen und die Teammitglieder in der Entwicklung des erfolgreicheren Produkts zu schulen.

Im konkreten Beispiel waren die Produkte in Bezug auf die verwendete Technologie sehr unterschiedlich und die meisten Mitarbeiter Freiberufler, so dass auch die Arbeit mit mehreren Product Backlogs und mehreren Product Ownern (also ohne LeSS) auch gut funktionierte. Die Interaktion zwischen den Teams war sehr gut, die Effizienz auf Teamebene war hoch und das erfolgversprechendste Produkt konnte identifiziert werden.

Wie läuft ein Remote Sprint Review in LeSS ab?

In einem echten LeSS-Setup würden Sie vielleicht ein paar Dinge anders durchführen wollen. Nach dem Check-in und bevor die Teams ihre Sitzungen pitchen, könnten Sie nur einen Block haben, in dem der Product Owner relevante Änderungen der Nutzungszahlen, spezielles Kundenfeedback und Updates vom Markt kommuniziert.

Sie könnten einen Bereich auf dem Board vorsehen, wo wichtige Zahlen und andere Erfolgsgeschichten (z.B. Go-Live einer Funktionalität) geteilt werden, aber ich würde sowohl die “Hindernisse” als auch die “nächsten Schritte” entfernen, oder zumindest würde ich sie nicht zu Beginn des Sprint Reviews diskutieren. Der beste Zeitpunkt, um Hindernisse zu besprechen, wäre während einer Gesamt-Retrospektive (mit allen Teams) und die nächsten Schritte bespreche ich lieber am Ende des Sprint Reviews und unter Einbeziehung des gesamten Feedbacks daraus, nicht am Anfang.

Nach dem Remote Review Bazaar sortieren und gruppieren die Teams den Input, den sie erhalten haben, und fassen ihn zusammen. Der Product Owner macht sich mit dieser Zusammenfassung vertraut, in dem er zwischen den Bereichen auf dem Miro Board oder zwischen den Breakout-Räumen der Teams hin- und her wechselt. Anschließend besprechen alle Teams mit dem Product Owner, welches Feedback in den kommenden Sprints eingearbeitet werden soll und wie dies geschehen kann. Häufig führt dies zur Erstellung von neuen Items, die im nächsten Backlog Refinement definiert werden, zur Veränderung von Prioritäten bestehender Items oder gar zur Entfernung von Items. Dieser Schritt im Sprint Review ist sehr wichtig, denn er gibt die Richtung für die Entwicklung vor. Hier empfiehlt es sich, genügend Zeit im Sprint Planning einzuplanen.

Nach meiner Erfahrung lässt sich die Retrospektive des Sprint Reviews verkürzen, indem man lediglich einen Abschnitt für Feedback auf dem Board vorsieht, oder diesen Abschnitt sogar vollständig weglässt, und das Feedback bei Bedarf in einer Gesamt-Retrospektive bespricht.

Hier sehen Sie, wie eine Agenda aussehen könnte:

Potential Agenda
Ich hoffe, dieser Artikel gibt Ihnen eine Idee, wie Sie ein Remote Sprint Review mit mehreren Teams durchführen können. Über Feedback und/oder Fragen würde ich mich sehr freuen.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Robert Briese nimmt regelmäßig Teilnehmer seiner pCLP-Kurse (Provisional Certified LeSS Practitioner) zu einem solchen Sprint Review mit. Wenn Sie also eine solche Veranstaltung live erleben wollen, können Sie an einem seiner Kurse teilnehmen oder ihm schreiben. Mehr über Robert erfahren Sie unter https://less.works/profiles/robert-briese oder auf seiner Firmenwebsite https://www.leansherpas.com.

Robert Briese hat im t2informatik Blog einen weiteren Beitrag veröffentlicht:

t2informatik Blog: 4 praktische Ideen zur Verbesserung von Sprint Reviews

4 praktische Ideen zur Verbesserung von Sprint Reviews

Robert Briese
Robert Briese

Robert Briese ist Coach, Berater und Trainer für agile und Lean-Produktentwicklung sowie Gründer und Geschäftsführer der Lean Sherpas GmbH. Als einer von nur 22 zertifizierten Large-Scale Scrum (LeSS) Trainern weltweit arbeitet er mit Einzelpersonen, Teams und Organisationen an der Einführung von Praktiken für agile und schlanke Entwicklungen sowie der Verbesserung der organisatorischen Agilität durch kulturellen Wandel.

Robert Briese hat mit (realen) Startups (Penta), Corporate Start-Ups (Ringier, Yello) und auch großen Organisationen (SAP, BMW, adidas) gearbeitet, um ein Organisationsdesign zu schaffen und Praktiken einzuführen, die schnelleres Kundenfeedback, Lernen und eine größere Anpassungsfähigkeit für Veränderungen ermöglichen. Er ist ein häufiger Sprecher auf Konferenzen und gibt regelmäßig Trainings in Large-Scale Scrum (LeSS).