Ich las die Tage einen Artikel über Product Discovery und da kam mir der Gedanke, dass es zwischen der Product Discovery und der Retrospektive ein paar Parallelen gibt.

In der Retrospektive geht es darum, den Prozess im Team besser zu verstehen und Lösungen zu finden, um diesen Prozess zu verbessern. Zu dem Prozess gehört für mich hier auch die Interaktion zwischen den Teammitgliedern, also Aspekte wie Teamwork, Vertrauen und psychologische Sicherheit, aber das nur am Rande.

In der Product Discovery geht es darum, die Bedürfnisse des Kunden besser zu verstehen und Lösungen abzuleiten, mit dem wir ihm das Leben leichter machen zu können.

Die Inhalte mögen natürlich im Detail verschieden sein, aber vom Grundsätzlichen her gibt es doch gewisse Ähnlichkeiten: sowohl in der Retrospektive als auch in der Product Discovery geht es darum Bedürfnisse und Probleme möglichst genau zu identifizieren und zu benennen um dann daraus möglichst passgenaue Lösungen abzuleiten.

Das wirft die Frage auf: können wir eventuell von Problemlösungsansätzen der Product Discovery auch etwas über die Retrospektive lernen?

Problemräume und Lösungsräume

Ein Konzept aus dem Produktmanagement sagt, dass man Anforderungen an ein Produkt gewissermaßen einer von zwei Perspektiven zuordnen kann: dem Problemraum (problem space) und dem Lösungsraum (solution space).

Der Problemraum ist der Raum, in dem die Bedürfnisse des Kunden und Problemstellungen im Vordergrund stehen. Hier geht es darum was wir tun könnten (im Sinne einer Zielsetzung), um bestehende Kunden glücklicher zu machen oder neue Kunden für uns zu gewinnen. Hier kann es um spezifische Probleme des Kunden gehen, um ungelöste Bedürfnisse, und wie der Zielzustand aussehen müsste, damit das Problem gelöst wird. Im Problemraum geht es nicht um das „Wie“ sondern viel mehr um das „Was“ und das „Warum“ – welches Bedürfnis ist unerfüllt und warum ist das ein Problem?

Der Lösungsraum dagegen ist der Raum, in dem es um mögliche Lösungen geht. Das ist der Raum, in dem wir den Hasen aus dem Hut zaubern, die technische Machbarkeit diskutieren und über Umsetzungsdetails sprechen. Gleichzeitig ist es höchstwahrscheinlich der Bereich, in dem sich die meisten Menschen wohl fühlen.

Dass sich Menschen im Lösungsbereich wohler fühlen als im Problembereich lässt sich häufig an vielen kleinen Einzelbeobachtungen erkennen. Wenn sich beispielsweise Stories mehr an einer möglichen Lösung als am eigentlichen Problem orientieren. Oder wenn während Diskussionen in Retros frühzeitig konkrete Lösungsansätze eingeworfen werden und schnell dazu übergegangen wird, ein Commitment für die Idee einzuholen, bevor die anderen Teilnehmer genügend Zeit hatten sich mit dem Thema auseinanderzusetzen, sich eine Meinung zu bilden oder ihre Gedanken zu dem Thema zu äußern.

Dass sich die Leute im Lösungsraum wohler fühlen ist verständlich. Wer will schließlich nicht Lösungen parat haben und wieder zu dem übergehen, was man am Besten kann? Und immerhin ist der Aufenthalt im Problemraum manchmal auch unangenehm. Gerade bei Retrospektiven, wo die Themen auch mit unangenehmen Fragen verbunden sein können, weil es da nicht um die Probleme des Kunden sondern um die eigene Arbeitsweise und – nun ja – auch Problemen damit geht.

Außerdem kann man vom Lösungsraum schnell zur Aktivität übergehen und das ist ja letztlich was zur Beseitigung des Problems führt.

Oder nicht?

Das Problem dabei ist, dass die dabei entstehenden Ideen nicht immer auch die geeignetesten Ideen sein müssen. Und das hängt nicht damit zusammen, dass es die erste Idee ist oder diese Idee schlecht ist – sondern damit, dass die Lösung eventuell ein anderes Problem löst als man tatsächlich hat. Denn eine gute Idee zeichnet ja vor allem eines aus: dass sie zum Problem passt. Dafür muss ich das Problem aber erstmal verstanden haben. Das kann natürlich auch bei der ersten, spontanen Idee der Fall sein, aber wenn ich zu wenig Zeit aufgewendet habe, um das Problem zu verstehen und auch aus verschiedenen Perspektiven zu betrachten, dürfte das wohl eher wie beim blinden Huhn sein, das ein Korn findet: ein Zufallstreffer.

Natürlich kann man davon ausgehen, dass die Menschen, die früh im Prozess ihre Ideen einbringen, das nicht unbedacht tun. Sehr wahrscheinlich haben sie schon eine gewisse Zeit darauf verwendet, das Problem aus ihrer Warte zu verstehen und vielleicht haben sie auch schon die Perspektive anderer Leute im Team eingeholt. Diese Aufwände sollte man auch nicht abtun, denn das sind natürlich Aktivitäten die sowohl zum Problemverständnis als auch zur Lösungsfindung beitragen. Zu bedenken gilt allerdings, dass ihr Bild von den Problemen nicht vollständig sein wird, sofern die anderen Leute im Team nicht die Gelegenheit hatten, ihr Wissen und ihre Erfahrung beizutragen. Immerhin ist es ja auch eine der grundlegenden Ideen cross-funktionaler Teams, dass bessere Ideen und Ergebnisse entstehen, wenn Leute aus unterschiedlichen Fachrichtungen oder mit unterschiedlichen Erfahrungen zusammen an etwas arbeiten.

Darüber hinaus spielt auch eine Rolle, dass Menschen dazu neigen, bei dem zu bleiben was sie schon kennen. Die Wahrscheinlichkeit, dass die vorgeschlagene Lösung sich an etwas orientiert, mit dem man in der Vergangenheit schon Erfahrungen gesammelt hat, ist also hoch (siehe auch: Law of the instrument).

An dieser Stelle könnte man anmerken, dass man ein Problem auch dadurch besser verstehen lernen kann, indem man eine Hypothese darüber in der Praxis validiert. Das ist richtig. Dann sollte man meiner Meinung nach das Problem aber zumindest so weit verstanden haben, dass man auch eine Hypothese formulieren kann und nicht einfach nur eine beliebige Idee testet. Aber dazu werde ich im weiteren Verlauf noch mehr sagen.

Welche Erkenntnisse können wir daraus beziehen?

Was können wir also machen um bessere also passfähigere Ideen zu finden?

Ich finde diese Metapher mit den Problem- und Lösungsräumen ziemlich nützlich. Wenn ich mir diese unterschiedlichen Räume vergegenwärtige, ist es relativ klar, dass ich in beiden Räumen genug Zeit verbringen sollte. Wenn ich einen Prozess habe, der dazu dient Lösungen für Probleme des Kunden oder in der Zusammenarbeit eines Teams zu finden, kann ich den Prozess derart gestalten das in beiden Räumen genug Zeit verbracht wird.

Dazu ist sicher hilfreich, sich einmal zu überlegen, was für Aktivitäten tendenziell eher dem einen oder dem anderen Lösungsraum zuzuordnen sind.

Aktivitäten im Problemraum

• Sammeln von Daten über den Sprint, die Stimmung im Team
• Brainstorming über Probleme die im Sprint aufgekommen sind
• Brainstorming über mögliche Ursachen für die Probleme und Einflussfaktoren
• Impact von Problemen analysieren – wie stark tragen die Problembereiche überhaupt zu Erfolg oder Misserfolg des Teams bei?
• Priorisierung von Problembereichen – womit sollten wir uns näher beschäftigen?
• Austausch von Meinungen zu dem Thema
• Blickwinkel der einzelnen Mitglieder im Team abgleichen
• Abgleich von Erwartungen der Teammitglieder an die Prozesse aber auch die Zusammenarbeit
• Rausfinden, wo uns noch Wissen über das Problem fehlt

Aktivitäten im Lösungsraum:

• Ideen sammeln wie Probleme gelöst werden können
• Ideen sammeln was wir tun könnten, um das oder die Probleme besser zu verstehen
• Sammeln von Dingen, die gut im Sprint gelaufen sind oder allgemein zu unserem Erfolg beitragen
• Diskussion von Lösungsvorschlägen
• Diskussion über Impact und Einwände zu Lösungsvorschlägen, Grenzen herausarbeiten
• Impact von Lösungsvorschlägen diskutieren – für wie wahrscheinlich halten wir es, dass die Idee umsetzbar ist und das Problem löst?
• Nächste Schritte festlegen – zum Beispiel Working Agreements ergänzen oder Dinge, an denen man im nächsten Schritt arbeiten kann
• Commitment im Team einholen – sicherstellen, dass die Teammitglieder den vorgeschlagenen Weg mit gehen

Die beiden Listen sind natürlich weder vollständig, noch ist die Abgrenzung zwischen Problem- und Lösungsbereich immer trennscharf, aber sie soll aufzeigen worum es grob gesagt geht, wenn man sich mehr auf den einen oder den anderen Bereich konzentriert.

Diese Aktivitäten müssen nicht zwangsläufig oder ausschließlich innerhalb des Meetings stattfinden, das wir Retrospektive nennen. Aber wenn man für diese einen groben Ablauf festlegen wollte, könnte der ungefähr so aussehen:

1. Informationen sammeln
2. Erkenntnisse generieren
3. Lösungsansätze sammeln und bewerten
4. Entscheidung über die nächsten Schritte

Wer das 5-Phasen-Modell für Retrospektiven kennt, wird hier gewisse Parallelen erkennen.

Das 5-Phasen-Modell ist aus meiner Sicht tatsächlich ganz praktisch, weil es eine Struktur bietet, mit der ich sicherstellen kann, dass ich mich zumindest einen Teil der Zeit im Problemraum als auch im Lösungsraum aufhalte. Nicht ganz trennscharf aber tendenziell könnte man nämlich sagen, dass die „Gather data“ und die „Generate insights“ Phasen und die dafür typischen Aktivitäten sich eher dem Problemraum zuordnen lassen, während die „Decide what to do“-Phase eher im Lösungsraum anzusiedeln ist.

Aber: Lösungsfindung ist ein kreativer Prozess und so sollte man das nicht zu sehr als linearen Ablauf verstehen und nach Schema F abarbeiten.

Im Kreativen können Strukturen helfen, indem sie als eine Art Katalysator dienen, aber es braucht eben gleichzeitig eine gewisse Freiheit, damit sich Kreativität überhaupt entfalten kann. Die Aufgabe des Facilitators oder Moderators der Retrospektive ist dementsprechend dafür zu sorgen, dass sowohl Zeit im Problem- als auch im Lösungsraum verbracht wird, dass die Teilnehmer Zeit und Raum haben in verschiedene Richtungen zu denken, ihre Standpunkte und ihr Wissen einzubringen und dass der Prozess trotzdem auf ein Ziel ausgerichtet bleibt. Das Ziel ist aber nie das Meeting schnell hinter sich zu bringen und irgendwelche Maßnahmen festgelegt zu haben, sondern den Prozess im Team nachhaltig zu verbessern.

Das kann wie oben schon einmal angeschnitten auch beinhalten, eine Idee erst einmal in der Praxis umzusetzen, um eine Hypothese über das Problem zu validieren. Das ist durchaus ein valider Verbesserungsansatz, denn immerhin arbeiten wir ja in agilen Arbeitsweisen vom Grundgedanken der Empirie geleitet. Das beinhaltet aber auch, dass ich mir zumindest ausreichend Gedanken über das Problem gemacht habe, sodass ich später nachfassen und überprüfen kann, ob dieses „Experiment“ die getroffene Hypothese bestätigt. Und besonders wichtig: da es bei der Retrospektive ja nicht um irgendein Produktfeature sondern um die Zusammenarbeit des Teams geht, sollte ich mir auf jeden Fall darüber Gedanken machen, dass das Experiment nicht schädlich für die Menschen im Team ist.

In der Product Discovery arbeitet man übrigens auch mit solchen Experimenten. Da kann das zum Beispiel der Prototyp eines neuen Produkts sein, den man verwendet um weitere Erkenntnisse über den Problemraum zu erlangen. Entsprechend würde man in solchen Experimenten versuchen sich nicht in Details zu verlieren oder ein tatsächlich marktfähiges Produkt zu schaffen.

Ebenso kann ich Aktivitäten zum Daten sammeln und Erkenntnisgewinn natürlich auch im Vorfeld einer Retrospektive stattfinden lassen. Ich könnte zum Beispiel eine Umfrage unter den Teammitgliedern zu einem bestimmten Thema starten, um die Ergebnisse in der Retro auszuwerten. Das kann meiner Meinung nach Sinn machen, damit die Leute genügend Zeit haben, über Dinge nachzudenken. Aber ich würde mich dabei auf Aktivitäten beschränken, bei denen eine bessere Datenlage für die eigentliche Retro im Vordergrund steht. Worum es nicht gehen sollte, ist das Thema im Vorfeld der Retro festzulegen oder einzelne Schritte in der Retro auslassen zu können. Denn das würde dem Team die Flexibiltät nehmen, die Themen zu behandeln, die ihnen zum Zeitpunkt der Retro wichtig sind, und in ausreichender Tiefe zu erörtern.

Wieviel Zeit sollte ich im Problem- und wieviel im Lösungsraum verbringen?

Wieviel Zeit ich auf Problemraum oder Lösungsraum verbringen sollte, hängt natürlich vom zu lösenden Problem ab und lässt sich deshalb nicht pauschal sagen.

Aber wenn Menschen tatsächlich dazu tendieren, sich im Lösungsraum wohler zu fühlen, ist die Wahrscheinlichkeit hoch, dass mehr Zeit mit Aktivitäten im Lösungsraum verbracht wird als damit die Probleme wirklich zu verstehen. Als Moderator oder Facilitator kann ich das aber auf verschiedene Arten beeinflussen.

Zuallererst kann ich dafür mal eine aktive Rolle als Facilitator einnehmen: durch Nachfragen und Denkanstöße die Gespräche stimulieren und den Leuten im Team den Raum schaffen, ihre Gedanken zu teilen. Dabei ist natürlich Fingerspitzengefühl gefragt, denn nicht jede Stille im Raum muss mit Worten gefüllt werden und eher introvertierte Teammitglieder durch direkte Ansprache zur Teilnahme „zwingen“ dürfte sich auch eher ungünstig auswirken. Hin und wieder kann ich als Facilitator auch eine eher beobachtende Rolle einnehmen und interessante Beobachtungen wiederum mit dem Team teilen. Dann kann ich natürlich intervenieren, wenn ich den Eindruck habe, dass zu schnell zur Diskussion von konkreten Ideen übergegangen wird oder wenn einzelne Personen zu viel Raum einnehmen, während andere kaum oder gar nicht im Gespräch eingebunden sind. Aber es sollte bei der Moderation eben nicht nur darum gehen in geeigneten Momenten zu intervenieren, sondern eher darum, eine Balance zwischen genügend Zeit und Raum für kreative Prozesse und einem auf ein Ziel ausgerichteten Prozess herzustellen.

Insgesamt ist es immer wieder spannend zu sehen, wie positiv es sich auf die Gespräche, auf den Erkenntnisgewinn und die Ideenfindung auswirken kann, wenn man die Rolle des Facilitators eher aktiv angeht und sich selbst nicht einfach nur als die Person auffasst, die das Meeting organisiert, die Anmoderation übernimmt und die Gespräche ansonsten sich selbst überlässt.

Ganz allgemein gesagt ist die Aufgabe des Facilitators Gespräche ans Laufen zu bringen, für die Einbeziehung möglichst aller Teammitglieder zu sorgen, und die Kreativität der Gruppe anzuregen.

Neben der aktiven Moderation kann ich auch durch die Wahl der Aktivitäten dazu beitragen, dass die Auseinandersetzung nicht nur an der Oberfläche kratzt.

So hilft es neben Aktivitäten zum Themen und Daten sammeln auch Aktivitäten einzubauen, die zur tiefergehenden Analyse einladen. Wenn sich das Team in einer Retro beispielsweise mit einem Misserfolg beschäftigt, könnte das Team mit einer Aktivität wie den 5 Whys ergründen, was denn eigentlich der Root Cause für das Problem war. Tatsächlich existiert eine große Anzahl möglicher Aktivitäten, die den Verbesserungsprozess im Team voran bringen können und oftmals auch noch einen weiteren entscheidenden Vorteil haben: dass sich bei ihnen auch Leute einbringen können, die in offenen Diskussionen eher zurückhaltend sind und dass sie auch Zeit bekommen für sich zu reflektieren.

Der Retromat kann beispielsweise helfen, passende Aktivitäten zu finden, und ansonsten existieren auch eine Vielzahl von Internetseiten und Büchern, die sich mit dem Thema beschäftigen. Ein aus meiner Sicht Standardwerk, das jeder Moderator und jede Moderatorin von Retrospektiven gelesen haben sollte, ist das Buch „Agile Retrospectives – Make Good teams great“ von Esther Derby und Diane Larsen (siehe auch mein Review zu dem Buch). Das Buch beinhaltet neben einer umfassenden Vorstellung einiger verschiedener Aktivitäten auch viele Tipps zur Moderation.

Zusammenfassend kann man sagen, dass es sowohl in der Product Discovery als auch in Retrospektiven darum geht Problemfelder ausreichend und von verschiedenen Seiten zu beleuchten und das man diesen Prozess nicht dem Zufall überlassen muss. Die Verantwortung dafür liegt natürlich wie immer beim Team insgesamt, der Agile Master, und in der Product Discovery der Product Owner, können diesen Prozess aber unterstützen und haben dafür eine Vielzahl von Werkzeugen und Techniken zur Verfügung.

Letztlich kommt es aber darauf an, dass genügend Zeit in eine qualitative Auseinandersetzung einerseits und kreative Lösungsfindung andererseits investiert wird und dass sich jeder einbringen kann.

Weiterführende Informationen

Die folgenden Artikel bieten weiterführende Informationen:

• Product Discovery: A practical guide for agile Teams (der Artikel, der zu diesem Artikel angeregt hat)
• 14 Tipps, die jeder Facilitator kennen sollte
  
• Tipps and tricks for facilitating Workshops and Meetings
• Ideation – Wie Ideen entstehen