Ich muss zugeben, der erste Fehler klingt etwas dramatisch.
Fehler #1: Die falschen Stakeholder werden eingeladen
Aber wenn du wüsstest, wie viele Sprint-Reviews ich schon besucht habe, bei denen die einzigen Gäste die Entwickler aus dem benachbarten Team waren, dann könntest du nachvollziehen, warum ich es so drastisch formuliere. Wenn die Entwickler aus dem benachbarten Team die falschen Stakeholder sind, wer sind dann die richtigen? Und hier schleicht sich häufig ein Fehler ein. Wir fragen nach Personen. Aber eigentlich sollten wir uns doch fragen:
Welches Feedback bringt die Produktentwicklung weiter?
Die Antwort auf diese Frage kann weiterhin lauten: Das Feedback der Entwickler aus dem anderen Team. Allerdings wird sie mit Sicherheit auch lauten: das der Nutzer, der Kunden, des Auftraggebers. Aber sie könnte auch lauten: Feedback aus der Marketingabteilung, dem PMO oder der Geschäftsführung. Es geht also nicht um die Person an sich, sondern um die Art des Feedbacks.
Bringt uns Feedback weiter,
- wie wir das Problem technisch gelöst haben,
- wie Nutzer das Produkt nutzen oder
- wie das Produkt in die Strategie des Unternehmens passt?
Wenn du diese Frage beantwortest, dann weißt du, wen du ins Sprint-Review einladen solltest oder welche Informationen präsentiert werden sollten.
Was meine ich mit „Informationen“? Wenn du entscheidest, dass das Feedback der Nutzer wichtig für die Weiterentwicklung des Produkts ist, könntest du Folgendes tun: Du könntest die Nutzer direkt ins Sprint-Review einladen. Dort hätten sie die Möglichkeit, das Produkt live auszuprobieren. Sollte dies nicht möglich sein, dann wähle Informationen aus, die das Feedback der Nutzer widerspiegeln. Vielleicht Informationen über die Zufriedenheit der Anwender in Form des Net-Promoter-Scores oder über die Unzufriedenheit in Form von Supportanfragen. Das meine ich hier mit „Informationen“. Und da die Beschaffung dieser Informationen meistens zeitintensiv ist, muss dies bereits vor dem Sprint-Review erledigt werden. Das zu versäumen erachte ich als Fehler, welcher das Scrum Team um wertvolles Feedback bringen kann.
Und wenn wir schon bei Informationen sind, hier ein weiterer Fehler:
Fehler #2: Die Produktwand ist nicht vorbereitet
Und gleich vorweg: Ich habe diesen Fehler auch jahrelang gemacht.
Dies änderte sich erst vor drei Jahren. Damals habe ich ein Sprint-Review bei Scrum.org besucht. Und alle Informationen für die Stakeholder – als Professional Scrum Trainer bin ich Stakeholder für die Trainings – wurden in Form einer Produktwand für uns zugänglich gemacht.
Wenn du dich jetzt fragst, was eine Produktwand ist, dann bist du nicht allein. Ich habe mich das auch gefragt, da das Konzept auch für mich neu war.
Eine Produktwand ist eine Praxis, bei der alle produktbezogenen Informationen an einem Ort erfasst und transparent gemacht werden. Dazu gehören Informationen wie Marktforschungsergebnisse, Kundeneinblicke und Technologietrends. Außerdem zählen die Produktvision, die Produktstrategie sowie die Ziele dazu. Auch objektive Ergebnisse und Werte sind wichtig. Produktmetriken und Personas sind ebenfalls Teil dieser Informationen. Und, und, und ... Jeder, der mehr über das Produkt erfahren möchte, kann die Produktwand besuchen und sich informieren. So beschreiben es Chris und Robbin in ihrem Buch „Practical Product Management for Product Owners“. Diese Praxis hat ihren Ursprung bei Toyota und heißt dort Obeya-Raum. Der Ausdruck bedeutet wortwörtlich: „großer Raum“. In unserem Kontext wird er besser mit „Brücke eines Schiffes“ übersetzt.
Eine Produktwand ermöglicht Stakeholdern in Sekunden einen Überblick über das Produkt zu gewinnen. Deshalb nutze ich Produktwände überall in meiner Arbeit. Auch im Coaching von Product-Ownern. Das Vorgehen hat sich sogar so bewährt, dass eine Produktwand auch in der Case-Study im „Professional Agile Leadership – Evidence-Based Management“-Training eingesetzt wird.
Hier ein Beispiel eines Metriken-Dashboards:
Was fällt dir auf? Mit einem Blick können wir sehen, dass wir ein Problem in der aktuellen Wertentwicklung des Produkts haben. Dieses Feedback liefert einen zeitsparenden Einstieg in die Diskussion, was wir als Nächstes tun sollten. Da die Erstellung und regelmäßige Aktualisierung einer Produktwand Zeit kostet, sollte dies noch vor dem Sprint-Review passieren. Geschieht das nicht, verpassen wir eine Möglichkeit, wertvolles Feedback zu erhalten.
Und beim Sammeln dieses Feedbacks kommt es schnell zu einem weiteren Fehler:
Fehler #3: Keine Möglichkeit, Feedback zu sammeln und auszuwerten
Endet das Sprint-Review in einer Diskussion? Dann solltest du das unbedingt ändern.
Das Sprint-Review ist ein Workshop. Nutze, dass die Stakeholder sich dafür Zeit nehmen, um so viele Informationen von ihnen zu erhalten wie möglich. Eine Diskussion ist aus meiner Sicht am wenigsten dafür geeignet. Und ein Fehler, der durch etwas Vorbereitung einfach vermieden werden kann.
Hier mal drei Möglichkeiten, wie du Feedback sammeln und auswerten kannst. Ich habe sie nach dem Aufwand der Vorbereitung geordnet. Ich empfehle dir, mit der ersten zu beginnen. Dann kannst du dich langsam steigern.
Erste Möglichkeit: Feedback-Matrix
Nachdem die neue Version des Produkts vorgestellt und ausprobiert wurde, bittest du die Stakeholder, diese vier Fragen zu beantworten:
- Mir gefällt: Dinge, die ich mag oder die mir gefallen haben ...
- Konstruktive Kritik: Ich hätte mir gewünscht ...
- Fragen? Fragen, die sich aus der Erfahrung oder Präsentation ergeben haben ...
- Ideen? Ideen, die sich aus der Erfahrung oder Vorstellung ergeben haben ...
Sammle die Antworten in dieser Matrix, um sie im Anschluss im Scrum Team auszuwerten.
Zweite Möglichkeit: 20/20-Sicht
Der ungewöhnliche Name „20/20-Sicht“ steht für die Fähigkeit, perfekt zu sehen, ohne eine Brille oder Kontaktlinsen tragen zu müssen. Mit der gleichnamigen Technik lassen sich gut Kundenwünsche priorisieren.
Hier das Vorgehen:
- Schreibe zunächst alle Einträge des Product-Backlogs auf große Karteikarten.
- Mische die Karten und lege sie als Stapel verdeckt ab.
- Nimm die erste Karte vom oberen Ende und klebe sie an die Wand.
- Nun nimm die nächste Karte vom Stapel und frage die Stakeholder, ob sie mehr oder weniger wichtig ist als die Karte an der Wand. Wenn sie wichtiger ist, klebe die Karte höher fest. Wenn sie weniger wichtig ist, hänge sie weiter unten auf.
- Wiederhole diesen Vorgang mit allen Karten.
Das Resultat ist eine „20/20-Sicht“ dafür, was die Stakeholder wirklich wollen.
Und zum Schluss noch eine Analyse-Technik:
Dritte Möglichkeit: Kano-Modell für Kundenzufriedenheit
Der beste Weg, die Kundenbindung zu verbessern, heißt, mehr Features zu entwickeln? Also der Prämisse folgen: Mehr Features bedeuten mehr zufriedene Kunden. Dr. Noriaki Kano, Professor für Qualitätsmanagement an der Tokyo University of Science, stellte das in Frage. In seiner Forschung fand er heraus, dass die Kundenbindung von der emotionalen Reaktion auf das Feature abhängt.
Hierfür definierte er drei emotionale Reaktionen auf ein Feature:
- „Must-have“-Feature
- Leistungs-Feature
- Begeisterungs-Feature
Und nur für Leistungs-Features bedeutet mehr Features zufriedenere Kunden. (Die Kano-Analyse ist ein Fass ohne Boden. Mehr findest du in diesem Artikel: „Mehr als 99 Einträge im Backlog? So mistest du das Backlog aus und priorisierst die wertvollsten Aufgaben – ohne Zeit für Abstimmungen zu verschwenden“) Wie kannst du das Kano-Modell nutzen, um Feedback zu sammeln?
Bitte etwa die Stakeholder im Sprint-Review, die Einträge des Product-Backlogs den drei Kategorien zuzuordnen. Diese Information liefert dir eine quantitativ wertvollere Rückmeldung, welche Features du in Zukunft priorisieren solltest, als nur eine Diskussion.
Möchtest du weiterhin lesen, wie du Fehler vermeidest und damit deine Scrum Events verbesserst? Dann gib diesem Artikel einen „Daumen hoch“.