Ankündigung:
Zur Vorbeitrug auf den Scrum Day in Stuttgart im Juni gibt es heute bereits einen Websession von Bernd Joussen zum Thema „Von Drama zu Delivery“. Die Session ist kostenlos. Hier findest du weitere Details.
Und jetzt zum Sprint-Review:
Willst du das Sprint Reveiw verbessern, musst du es besser moderieren. Allerdings gebe ich dir keine Liste von 25 Techniken zur Moderation. Das ist nicht, was du brauchst.
Was du brauchst, ist ein Verständnis für Psychologie.
Du musst wissen, welche Denkfehler sich im Sprint-Review einschleichen. Denn diese Fehler führen dazu, dass die Ergebnisse des Sprints falsch interpretiert werden, Stakeholder ein falsches Bild vom Fortschritt bei der Erreichung des Produktziels haben und damit falsche Prioritäten für den nächsten Sprint gesetzt werden. Erst wenn du mehr über die psychologischen Effekte weißt, kannst du die richtigen Techniken wählen. Damit vermeidest du gängige Fehler und hilfst deinem Team, Konflikte mit Stakeholdern über den Fortschritt und die Priorisierung frühzeitig zu vermeiden.
Beginnen wir mit dem ersten Fehler:
Denkfehler #1: Der Bestätigungsfehler
Denken Menschen rational?
Im beruflichen Kontext wäre es wünschenswert. Allerdings hat die Wissenschaft dies längst widerlegt. Es gibt dutzende Denkfallen, in die wir Tag für Tag tappen. Viele dieser kognitiven Verzerrungen – also, dass wir die Wirklichkeit anders interpretieren, als sie ist, – lassen sich auf einen Fehler zurückführen.
Den Bestätigungsfehler.
Dieser Fehler bezeichnet die Tendenz, Informationen so auszuwählen und zu interpretieren, dass sie die eigenen Überzeugungen oder Annahmen bestätigen, während widersprechende Informationen ignoriert werden. Ein bekanntes Beispiel: Menschen, die ihrem Horoskop vertrauen, finden Ereignisse in ihrem Leben, die zu den Vorhersagen passen, während sie widersprüchliche Ereignisse eher ignorieren.
Okay. Aber keine Angst, ich denke jetzt nicht, dass dein Team seine Zeit mit Horoskopen verbringt.
Situationen, in denen der Bestätigungsfehler im Review auftreten kann:
Verzerrung des Teamerfolgs:
Ein Entwickler glaubt fest daran, dass die Modernisierung der Codebasis mit einem neuen Frontend-Framework die Programmierung zukünftiger Funktionen erheblich vereinfachen würde. Im Sprint-Review stellt er die Änderungen vor und deutet die Rückmeldung von Entwicklern aus anderen Teams als positives Signal, weitere Modernisierungen durchzusetzen. Die Rückfragen vom Vertrieb, wie diese Änderungen den Endkunden nutzen, überhört er.
Fehlinterpretation von Nutzerfeedback:
Der Accountmanager und seine Kollegin vom Vertrieb berichten während des Sprint-Reviews, dass das neue KI-Feature gut bei den Kunden ankommt. Da der Product-Owner sehr stolz darauf ist, dass er diesen Trend frühzeitig erkannt hat, nimmt er diese Aussage unkritisch als Bestätigung, dass das Feature perfekt ist, ohne das Nutzerverhalten oder Feedback im Appstore genauer zu analysieren.
Nutzerfeedback und der Erfolg des Teams können leicht fehlinterpretiert werden, wenn persönliche Voreingenommenheiten und fehlende Diversität in den Perspektiven das Gesamtbild trüben.
Ach, noch eine Bemerkung, bevor wir darüber sprechen, wie du diesen Fehler verhindern kannst:
Diese Denkfehler machen Entwickler, Stakeholder und Product-Owner nicht mit Absicht. Sie schleichen sich unbemerkt ein.
Jetzt:
Wie kannst du sie verhindern und das Sprint-Review erfolgreicher gestalten?
Spiele den „Advokaten des Teufels“:
In Situationen, in denen scheinbar alle Personen einer Meinung sind, argumentierst du absichtlich entgegen. Suche quasi absichtlich das Haar in der Suppe.
Und stelle (über)kritische Fragen, wie:
- Wer profitiert denn von dieser technischen Verbesserung?
- Bedeutet ein unzufriedener Kunde nicht, dass der Sprint ein Fehlschlag war?
- Sollten wir nicht auch weiteres Feedback einholen, bevor wir die Erfolge feiern?
Damit hilfst du deinem Team und den Stakeholdern, nicht nur Informationen zu betrachten, die ihren Überzeugungen entsprechen.
Was uns zum nächsten Fehler bringt:
Denkfehler #2: Der Halo-Effekt
Warum ist es wichtig, beim Vorstellungsgespräch einen guten ersten Eindruck zu machen?
Eine charismatische Person wird automatisch als kompetenter wahrgenommen, auch wenn es dafür keine Beweise gibt. Das Phänomen dahinter ist als Halo-Effekt bekannt. Der Halo-Effekt beschreibt die Tendenz, eine einzelne positive (oder auch negative) Eigenschaft einer Person, eines Produkts oder einer Situation so stark zu gewichten, dass sie die Wahrnehmung aller anderen Eigenschaften beeinflusst.
Im Gegensatz zum Bestätigungsfehler suchen wir nicht nach Informationen, die unsere Überzeugung bestätigen, sondern gewichten einzelne Informationen übermäßig.
Wie zeigt sich dieser Fehler im Sprint-Review?
Nur Präsentation von gelungenen Arbeiten:
Das Scrum Team stellt nur die neuen Features vor. Die Features, die nicht fertig wurden oder die nicht auf das Sprintziel einzahlen, werden nicht präsentiert. Welche Bugs behoben wurden und wie viel Zeit für Wartungsarbeiten aufgewendet wurde, wird nicht vorgestellt. Dadurch kann es passieren, dass Stakeholder den Erfolg des Teams mit der Anzahl der neuen Features gleichsetzen.
Präsentation durch charismatische Teammitglieder:
Wer stellt die Arbeit im Sprint-Review vor? Der Product-Owner, weil er gut vor Menschen sprechen kann, oder der Entwickler, der das Feature entwickelt hat? Ersteres kann dazu führen, dass das Feature von den Stakeholdern besser eingeschätzt wird, als es tatsächlich ist. Die Eigenschaft des Product-Owners, gut zu sprechen, wird dann von den Stakeholdern mit der Qualität des Features gleichgesetzt.
Was und wie etwas im Sprint-Review vorgestellt wird, kann dazu führen, dass der tatsächliche Zustand des Produkts oder der Fortschritt für die Stakeholder falsch bewertet wird.
Wie kannst du den Halo-Effekt im Sprint-Review verhindern?
Es braucht mehr Perspektiven.
Was meine ich damit? Dem Halo-Effekt sind Tür und Tor geöffnet, wenn es keine weiteren Informationen über und Perspektiven auf die Situation gibt. Wenn sich im Sprint-Review alles um fertige Features dreht, dann werden diese schnell zum Erfolgsmaß des Teams. Schon allein aus dem Grund, dass es keine Alternativen gibt. Biete deshalb Alternativen. Zeige auch noch die anderen Ergebnisse des Sprints.
- Welche Prozessverbesserungen wurden umgesetzt?
- Wie viel Zeit beanspruchen Wartung und Kundensupport?
- Wie häufig werden die Features des letzten Sprints auch von Nutzern genutzt?
- Was machen die Mitbewerber?
Der Scrum Guide schreibt deshalb auch:
„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.“
Im Sprint-Review sollen die Stakeholder und das Team also eine möglichst breite Sicht auf die Situation des Produkts erhalten. Je breiter die Sicht, desto unwahrscheinlicher ist es, dass eine einzige Information über den Erfolg des Teams entscheidet – also der Halo-Effekt eintritt.
Zum Abschluss noch ein Fehler, der wirklich in jedem Meeting auftritt und somit leider auch im Sprint-Review:
Denkfehler #3: Das Gruppendenken
Im Jahr 1985 führten die Psychologen Garold Stasser und William Titus ein Experiment durch:
Zwei Gruppen zu je vier Personen mussten entscheiden, welcher von drei Kandidaten am besten für das Amt des Studentenschaftspräsidenten geeignet war. Die Forscher erstellten Dossiers, die die positiven und negativen Eigenschaften der einzelnen Kandidaten enthielten. Auf dieser Grundlage war Kandidat A der Geeignetste für dieses Amt.
In der ersten Gruppe lasen alle Mitglieder das Dossier im Vorfeld, gaben ihre persönliche Präferenz an und wählten dann in einer Abstimmung als Gruppe Kandidat A. Soweit nichts Ungewöhnliches. Nun zur zweiten Gruppe: Hier waren die Dossiers für die Mitglieder unvollständig. Sie enthielten einige gemeinsame Informationen über jeden Kandidaten, aber die restlichen Informationen waren über verschiedene Dossiers verstreut. Aufgrund der Verteilung der positiven und negativen Informationen gaben die meisten Mitglieder vor der Abstimmung Kandidat A nicht den Vorzug. Obwohl die Mitglieder dieser Gruppe wussten, dass ihre Dossiers nicht alle Informationen enthielten, stellte sich in der Gruppendiskussion schnell ein Konsens ein.
Und dann geschah etwas Unerwartetes:
Sobald die Mitglieder der Gruppe sahen, dass sich ein Konsens bildete, wurde es zunehmend unwahrscheinlicher, dass Mitglieder mit abweichenden Informationen (negative über den Konsenskandidaten oder positive über die nicht bevorzugten Kandidaten) diese Informationen weitergaben. Anders als in den Gruppen mit vollständigen Informationen, in denen Kandidat A gewählt wurde, wählten diese Gruppen fast immer einen der anderen Kandidaten.
Nochmal überspitzt formuliert:
Ein Team von klugen Menschen trifft dümmere Entscheidungen, weil jeder seine Meinung dem vermeintlichen Konsens anpasst.
Wo tritt Gruppendenken im Sprint-Review auf?
Beim Unterdrücken von Meinungen:
Der Product-Owner, die Stakeholder, der Scrum Master und so gut wie alle Entwickler sind sich einig, dass im nächsten Sprint unbedingt an den Sprach-Features gearbeitet werden sollte. Der Designer hat Bedenken. Er fürchtet, dass es zu Lasten der Benutzbarkeit gehen wird und Nutzer mehr verwirren könnte, als es ihnen hilft. Er traut sich aber nicht, diese Bedenken zu äußern.
Werden nicht alle Meinungen geäußert, dann kann dies zu einer schlechten Priorisierung führen.
Wie kannst du Gruppendenken im Sprint-Review verhindern?
Gruppendenken kannst du verhindern, indem du jegliche Gruppendiskussion verhinderst.
Natürlich ist das nicht hilfreich im Sprint-Review. Deshalb solltest du Differenzen fördern.
Hier zwei Vorschläge:
- Nutze 1-2-4-All oder einen Redestab in Gruppendiskussionen, damit auch jeder zu Wort kommt und nicht nur die „Lauten“ sprechen.
- Nutze White-Elephant oder Dot-Voting, um bei Abstimmungen jedem im Termin eine Stimme zu geben.
Gruppendenken lässt sich besonders mit guter Facilitation verhindern. Gute Facilitation verbessert das Sprint-Review deines Teams. Aber erst gepaart mit Wissen über die menschliche Psychologie, denn nur so kannst du eine passende Methode zur Moderation wählen, die Denkfehler im Team und bei Stakeholdern ausgleicht.
Willst du den nächsten Schritt deiner Scrum-Master-Karriere gehen? Suchst du konkrete Tipps für deine Situation? Möchtest du dich mit anderen Scrum Mastern austauschen? Dann besuche unser nächstes „Professional Scrum Master - Advanced“-Training. Dort unterstützen Marc und ich dich auf deinem Weg, ein besserer Scrum Master zu werden.