4 praktische Ideen zur Verbesserung von Sprint Reviews

Zahlreiche Organisationen maximieren nicht den Erfolg, den sie mit Scrum haben könnten, da sie sich im Sprint Review vor allem auf folgende Punkte konzentrieren:

• Die Entwickler präsentieren dem Product Owner die im letzten Sprint geleistete Arbeit und beantworten Fragen zum Inkrement.
• Der Product Owner akzeptiert die Elemente, die „erledigt“ wurden, und entscheidet, was nicht „erledigt“ wurde.
• Das Team feiert die Leistung und geht zum nächsten Event, dem Sprint Planning, über.

Während alle diese Dinge entweder im Scrum Guide erwähnt werden oder in vielen Organisationen als „gute Praktiken“ gelten, fehlt nach meiner Erfahrung aber etwas Wesentliches: der Wille, das Produkt wirklich zu inspizieren und anzupassen, und sich kontinuierlich darauf zu konzentrieren, was als Nächstes zu tun ist, um den Lieferwert zu maximieren.

Wie können Organisationen aus einem Sprint Review das Beste herausholen? So geht es:

• Beteiligen Sie echte KundInnen und/oder EndbenutzerInnen am Sprint Review!
• Lassen Sie den Product Owner (oder jemanden, der ihn unterstützt) Einblicke in die Leistung des Produkts, die bestehenden Zeitpläne, Budgets und Marktchancen geben, damit Sie möglichst relevantes Wissen über das Produkt gewinnen!
• Lassen Sie KundInnen und/oder EndbenutzerInnen die Funktionen des Produkts, die das Team implementiert hat, so weit wie möglich selbst erleben!
• Geben Sie TeilnehmerInnen die Möglichkeit, aktiv daran mitzuarbeiten, wie das Product Backlog angepasst werden kann, um das Feedback zu reflektieren und daran zu arbeiten, was als Nächstes am wichtigsten ist (wobei der Product Owner das letzte Wort hat)!

Auf diese vier Ideen möchte ich nachfolgend genauer eingehen:

Beteiligen Sie echte KundInnen und/oder EndbenutzerInnen am Sprint Review!

Scrum schlägt vor, Stakeholder in das Sprint Review einzubeziehen, aber oft sehe ich nur Entwickler, die dem Product Owner und manchmal Product Ownern aus anderen Teams das Produktinkrement präsentieren.

Oft ist dies ein Zeichen dafür, dass es sich um ein Komponenten-Team handelt, dass sich nur auf einige technische Teile eines bestimmten Systems konzentriert, die mit der Arbeit anderer Teams integriert werden müssen, was automatisch zu einer Wasserfallentwicklung führt. Dies lässt sich nur ändern, wenn Sie Ihre Organisationsstruktur dahingehend ändern, dass Feature-Teams gebildet werden, die End-to-End-Kundenanforderungen umsetzen, wie es bspw. LeSS vorschlägt.

Doch selbst wenn Feature-Teams gebildet werden, verzichten sehr viele Unternehmen darauf, das Sprint Review mit realen KundInnen oder EndbenutzerInnen durchzuführen, da sie sich nicht sicher sind, wie sie die richtigen Leute finden, motivieren und einbeziehen sollten.

Wenn Sie ein internes Produkt (z. B. ein CRM-System) entwickeln, sollten die KundInnen die Personen sein, die dieses System nutzen. Das bedeutet, dass es nicht schwierig sein sollte, sie zu finden und zu motivieren, an Ihrem Sprint Review teilzunehmen. Wenn Sie ein für den Markt bestimmtes Produkt entwickeln, verfügen Sie in der Regel über eine Marketingabteilung (falls die MitarbeiterInnen nicht in den Teams integriert sind) sowie über eine ausgewählte Gruppe von ErstanwenderInnen, die Ihr Produkt lieben und ausgiebig nutzen. Auch in diesem Fall sollte es nicht allzu schwer sein, zumindest einige Personen aus diesen Gruppen in Ihr Sprint Review zu integrieren. Falls Sie aber keine solche Personen haben, sollten Sie evtl. überdenken, ob es sich lohnt, mehr in die Produktentwicklung zu investieren.

Lassen Sie den Product Owner Einblicke in die Leistung des Produkts, die bestehenden Zeitpläne, Budgets und Marktchancen geben!

Das Sprint Review sollte allen an der Produktidee, Produkterstellung, Produktlieferung und Produktnutzung Beteiligten die Gelegenheit bieten, zu beurteilen, ob das richtige Produkt bzw. die richtigen Features entwickelt und geliefert wurden.

Dies ist einer der wichtigsten Teile der empirischen Prozesskontrolle. Es ergibt keinen Sinn, in kurzen Iterationen zu liefern, wenn man nicht gründlich analysiert, ob man an den richtigen Dingen arbeitet, und die Richtung ändert, wenn man merkt, dass das nicht der Fall ist.

Um dies richtig einschätzen zu können, müssen Sie sich konkrete Daten ansehen, z. B.

• wie viele Nutzer Sie tatsächlich haben,
• wie oft die neuen Funktionen genutzt werden und vor allem,
• ob die neu entwickelten Produktfunktionen zu den gewünschten Auswirkungen führen.

Ich persönlich verwende hierfür gerne Techniken wie das Impact Mapping, aber zumindest ist es eine gute Idee, aufschlussreiche Daten über die Produktnutzung für alle TeilnehmerInnen des Sprint Reviews vorzubereiten. Dies kann vom Product Owner vorbereitet oder an andere Produktmanager delegiert werden, aber natürlich muss der Product Owner die Zahlen im Griff haben, um wichtige Produktentscheidungen treffen zu können.

Wenn es einen offiziellen Zeitplan für die Veröffentlichung gibt, ist das Sprint Review auch eine Gelegenheit, die Erwartungen der Stakeholder abzuklären. Achten Sie außerdem darauf, Feedback zu den Budgetzahlen zu geben, die der Product Owner als Verantwortlicher für den Return on Investment (ROI) des Produkts verwalten sollte. Alle anderen wichtigen Erkenntnisse über Marktveränderungen und -chancen, die für alle an der Produktentwicklung, Produkterstellung, Produktbereitstellung und Produktnutzung Beteiligten wichtig sind, können ebenfalls im Sprint Review kommuniziert werden.

Lassen Sie KundInnen und/oder EndbenutzerInnen die Funktionen des Produkts, die das Team implementiert hat, so weit wie möglich in der Praxis erleben!

In der Praxis haben viele Teams mit diesem Punkt zu kämpfen. Einerseits ist es großartig, Entwickler zu befähigen und zu motivieren, den KundInnen und/oder EndbenutzerInnen neu implementierte Funktionen zu präsentieren, doch oftmals haben entsprechende Demos gravierende Nachteile:

• Die Entwickler zeigen, was sie getestet haben und was funktioniert hat (oder idealerweise, was die automatisierten Tests geprüft haben).
• In der Regel erklären sie, wie und warum sie die Funktion auf eine bestimmte Weise nutzen würden.
• Das Feedback beschränkt sich auf einige wenige Personen, denen während der Demo etwas auffällt und die sich nicht scheuen, es zu erwähnen.

Anstatt Entwicklern die neu implementierten Funktionen präsentieren zu lassen, schlage ich vor, allen TeilnehmerInnen des Sprint Reviews die Möglichkeit zu geben, die Funktionen so praxisnah wie möglich zu erleben. Dies können Sie erreichen,

1. indem Sie den TeilnehmerInnen ein Gerät aushändigen,
2. den Link zu der Software/Anwendung geben oder
3. einige Papier-/Digitalprototypen auf ein (virtuelles) Whiteboard zur Verfügung stellen.

Häufig ist es sinnvoll, kurze Beschreibungen oder konkrete Fragen zu den Funktionen mitzuliefern, sodass Sie zielgerichtetes und inhaltlich wertvolles Feedback erhalten.

Dieser Ansatz hat verschiedene Vorteile:

• Die Entwickler können beobachten, wie die KundInnen das Produkt/die Funktionen tatsächlich wahrnehmen und nutzen.
• Die BenutzerInnen werden bei der Verwendung der Funktionen nicht beeinflusst (was die Realität widerspiegelt, in der Ihre KundInnen keine Erklärung zu jeder neuen Funktion erhalten, wenn sie ein bestimmtes Produkt verwenden).
• Die Entwickler erleben manchmal, dass das Verhalten der KundInnen ganz anders ist als erwartet, was ihnen hilft, in Zukunft bessere Lösungen zu finden.

 

Geben Sie TeilnehmerInnen die Möglichkeit, aktiv an der Anpassung des Product Backlogs mitzuarbeiten!

Neben der Möglichkeit für die TeilnehmerInnen, das Inkrement des Sprints so praxisnah wie möglich zu erleben, sollten Sie ihnen auch die Chance geben, so viel Feedback wie möglich zu geben.

Ich ziehe es vor, dies zu tun, indem ich dafür sorge, dass viele Post-its und Stifte neben dem Gerät oder dem Papierprototypen bereitliegen. Und wenn ich das Review virtuell durchführe, lasse ich das Team bspw. Screenshots der zu überprüfenden App-Bildschirme auf einem virtuellen Whiteboard erstellen, auf dem die TeilnehmerInnen anschließend direkt ihr Feedback hinterlassen können. Natürlich können Sie auch zusätzliche Fragen stellen, z. B. welche Funktionen derzeit fehlen oder welche Funktionalitäten anders gewünscht werden. Wenn Sie das entsprechend in die Tat umsetzen, werden Sie erstaunt sein, wie viel wertvolles Feedback Sie im Vergleich zu einer „reinen Demo“ erhalten.

Aber der entscheidende Teil beginnt erst, wenn Sie alle Rückmeldungen erhalten haben. Denn wie bereits erwähnt, ergibt eine iterative und inkrementelle Entwicklung wenig Sinn, wenn Sie das Backlog nicht ständig anpassen und sicherstellen, dass Sie an den Punkten arbeiten, die auf der Grundlage des jüngsten Feedbacks und des aktuellen Verständnisses den höchsten Wert für das Unternehmen/die KundInnen haben. Sie wollen also das gesamte Feedback destillieren und eine Entscheidung darüber treffen,

• welches kritische Feedback Sie haben und sofort bearbeiten wollen (vielleicht schon im nächsten Sprint),
• welches wichtige Feedback es gibt, das Sie in einem zukünftigen Product Backlog Refinement diskutieren und neu bewerten wollen, und
• welches Feedback im Moment nicht wichtig ist.

Sie können dies tun, indem Sie alle Rückmeldungen gruppieren und die Gruppen in verschiedene Kategorien einteilen. Letztendlich sollte der Product Owner die endgültige Entscheidung über die Priorisierung treffen, aber je mehr TeilnehmerInnen Sie in die Überprüfung, Gruppierung und Differenzierung des Feedbacks einbeziehen, desto besser werden sie die Kundenbedürfnisse und den Zweck des Produkts verstehen.

Fazit

Nutzen Sie die 4 praktischen Ideen zur Verbesserung Ihrer Sprint Reviews. Durch diese „einfachen“ Änderungen erhalten Sie hochgradig interaktive Veranstaltungen, bei denen jeder Produktschöpfer/-entwickler direkt mit den KundInnen und/oder EndbenutzerInnen des Produkts interagiert und versteht,

• wie das aktuelle Produkt seinen Zweck erfüllt und
• was sie als Nächstes implementieren müssen, um die Probleme der KundInnen zu lösen oder ihnen zu helfen, ein besseres Ergebnis mit dem Produkt zu erzielen, das sie erstellen.

 

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk.

Wenn Sie ein Sprint Review erleben möchten, bei dem alle oben genannten Vorschläge demonstriert werden, melden Sie sich für den Lean Sherpas LeSSons Learned Newsletter an. Robert Briese ermöglicht es KundInnen und KlientInnen gerne, an realen Sprint Reviews teilzunehmen, und die Lean Sherpas live in Aktion zu sehen.

Robert Briese hat im t2informatik Blog zwei weitere Beiträge veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.