Wer in der agilen Community unterwegs ist, hat wahrscheinlich schon einmal von Refinement Meetings gehört. Aber worum geht es dabei, und welches Potential schlummert noch darin?
Und wenn wir schon dabei sind: Wer hat schon einmal davon gehört, geschweige denn in einem Produkt Trio gearbeitet?
Wir sind der Meinung, dass es einen beträchtlichen Mehrwert liefert, etwas mehr Mühe und Fokus in Refinements zu stecken, als dies normalerweise der Fall ist, indem man sie mit einem Produkt Trio Ansatz kombiniert. Das kann für viele Leute eine ziemliche Zeitinvestition sein. Aber bei Spaceteams hat sich dieser Ansatz bereits in vielen Situationen ausgezahlt.
Was ist Refinement?
Früher war es eines der Scrum Events, bis es in der Version von 2020 aus dem Scrum Guide entfernt wurde.
Refinement selbst wird im Scrum Guide immer noch erwähnt und erklärt als:
„Das Refinement des Product Backlogs ist der Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.”
💡Wir denken, dass im Refinement Prozess von User Stories und Backlog Elementen viel Potential steckt, das freigesetzt werden kann, wenn man über die Grundlagen hinausgeht und es mit dem Ansatz des Produkt Trios kombiniert.
Was ist das Produkt Trio?
Teresa Torres, Autorin von Continuous Discovery Habits, beschreibt das Produkt Trio im Zusammenhang mit der Produkt Discovery wie folgt (Übers. d. Verf.):
„Ein Produkt Trio besteht in der Regel aus einem Produktmanager, einem Designer und einem Softwareentwickler. [...]
Ein Produkt Trio ist zusammen für ein gemeinsames Ergebnis verantwortlich. Sie befragen Kunden gemeinsam. Sie skizzieren gemeinsam den Raum der Möglichkeiten. Sie wählen gemeinsam eine Zielmöglichkeit aus. Sie entwickeln gemeinsam Lösungen. Und sie testen und entwickeln diese Lösungen iterativ gemeinsam. [...]
Wenn ein Produkt Trio zusammenarbeitet, um ein gemeinsames Verständnis des Kunden zu entwickeln, sind sie in einer viel besseren Position, Produkte zu entwickeln, die die Kunden lieben.“
Warum die Kombination von Refinement und Produkt Trio?
Wenn das Produkt Trio als nützlich für Discovery angesehen wird, warum ist es dann im Zusammenhang mit Refinement hilfreich, das nach der Discovery stattfindet?
In unserer Projektrealität entwickeln wir in der Regel eine maßgeschneiderte Software als Teil einer Wertschöpfungskette und selten ein eigenständiges Produkt. Das bedeutet, dass wir die Benutzer verstehen und uns mit vor- und nachgelagerten Systemen abstimmen müssen, während wir gleichzeitig das Erreichen der übergreifenden Unternehmens- und Geschäftsziele unterstützen, z. B. die Umstrukturierung und Automatisierung von Geschäftsprozessen.
Das bedeutet, dass es viele verschiedene Personen gibt, mit denen man über verschiedene Aspekte der erforderlichen Funktionen des Systems sprechen muss. Unter diesen Umständen ist es oft schwierig, die Zeit oder das Budget aufzubringen, um ein Produkt Trio für eine angemessene Discovery zusammenzubringen. Der PO muss jede Gelegenheit nutzen, um Anforderungen und Bedürfnisse herauszufinden und sie an das Entwicklungsteam weiterzugeben.
Und genau hier kommt das Refinement ins Spiel.
Manchmal bringt der PO ein Backlog Element mit, in der Regel eine User Story, die unglaublich detailliert ist und in manchen Fällen sogar Implementierungsdetails enthält. Ein anderes Mal ist die Story kaum selbsterklärend.
Die meisten POs sind keine Entwickler. Und in der Regel besteht ein PO nur aus einer Person.
Warum also nicht die Intelligenz des gesamten Entwicklungsteams während des Refinements nutzen, um die User Story zu hinterfragen, und zwar im Hinblick auf bekannte Schmerzpunkte, den Mehrwert der User Story und die geeignete Implementierung?
Nach unserer Erfahrung hat dies viele Vorteile:
- Der PO muss keine Zeit damit verschwenden, eine Story bis ins letzte Detail zu spezifizieren.
- Das gesamte Team gewinnt ein detailliertes Verständnis für die Bedürfnisse und Anforderungen der Nutzer:innen
- Die Lösung für den Nutzerbedarf kann nicht nur von der geschäftlichen Seite her betrachtet werden, sondern auch unter Berücksichtigung der technischen Möglichkeiten und Einschränkungen
- Das so verbesserte Verständnis
- ermöglicht oft eine reibungslosere Implementierung
- und reduziert den Abstimmungsbedarf, Folgefragen und Diskussionen während der Implementierung
Welche Hürden gilt es zu überwinden?
Der Ansatz des Produkt Trios ist für sich genommen bereits aus vielen Gründen schwierig in die Praxis umzusetzen. Zeit- und Budgetbeschränkungen sind die offensichtlichsten. Welches Unternehmen oder welcher Kunde ist bereit für Meetings mit einer großen Gruppe von Personen zu zahlen, insbesondere wenn diese Personen besser mit anderen Dingen beschäftigt wären, z. B. wenn Entwickler:innen programmieren sollten? Falls so eine Besprechung stattfindet muss sie sehr gut moderiert werden, um das Beste aus der investierten Zeit zu machen (aber was das heißt kann alleine einen ganzen Blogbeitrag füllen).
Und dann ist da noch der menschliche Faktor. Der PO, der UX/UI-Designer und das Entwicklungsteam haben alle ihre eigene Rolle, ihre eigenen Maßstäbe, an denen ihre Arbeit gemessen wird, und vielleicht auch ihre eigene Agenda. Im besten Fall wollen sie alle nur das Beste für den Kunden. Und dennoch ist damit nicht sichergestellt, dass sie sich darüber einig sind, was das Beste tatsächlich ist.
In unserer Projektarbeit arbeiten PO, Designer und Entwicklerteam oft getrennt voneinander. Sie sind nicht - oder agieren nicht als - ein Team. Der Designer ist oft für mehr als ein Team verantwortlich und hat nur sehr wenig Zeit für Abstimmungstermine. Der PO steckt tief in der Discovery, in der Unternehmenspolitik und im Umgang mit den verschiedenen Bedürfnissen von Stakeholdern und Nutzer:innen; manchmal hat er ohnehin schon Mühe, das Backlog rechtzeitig zu füllen.
Warum sich also die Mühe machen?
Bei solchen Hürden, regelmäßig zusammenzukommen, um Zeit mit dem Refinement von User Stories zu verbringen, die der PO theoretisch auch selbst schreiben könnte, muss es wirklich überzeugende und starke Vorteile geben, um die Investition aufzuwiegen.
Wir glauben, dass es das wert ist!
Nicht nur aus den oben genannten Gründen, dass man das Produkt besser versteht, die Qualität des Ergebnisses verbessert und die Reibung während der Entwicklung verringert. Sondern auch, weil es die Verantwortung des Entwicklungsteams für das Produkt deutlich erhöht.
Wir legen bei Spaceteams sehr viel Wert auf die Eigenverantwortung.
Es ist das starke Gefühl der Eigenverantwortung, das uns dazu antreibt, die von uns entwickelten Produkte zu verstehen, das uns fordert, sie innerhalb des erforderlichen Zeitrahmens so gut wie möglich zu machen und, was am wichtigsten ist, fokussiert zu bleiben und zu liefern.
Unserer Erfahrung nach geben uns die Ergebnisse Recht. Die Qualität der Lösung ist besser, wenn wir Refinement im Stil eines Produkt Trios durchführen. Und alles, was gebaut wird, ist dann viel besser auf die übergeordneten Unternehmensziele unserer Kund:innen abgestimmt.