Häufig kann man in Scrum Teams beobachten, wie der Product Owner (oder ein Proxy PO/ Requirements Engineer) sich um Product Discovery kümmert und das Development Team um die Product Delivery.
Dies widerspricht jedoch einigen der Prinzipien aus dem agilen Manifesto. Dort heißt es beispielsweise:
- “Business people and developers must work together daily throughout the project”
- “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”
- “Continuous attention to technical excellence and good design enhances agility” und nicht zuletzt
- “The best architectures, requirements, and designs emerge from self-organizing teams”
Viele dieser Dinge sind nur möglich, wenn der PO und das Dev Team wirklich zusammenarbeiten.
Denn, wie soll das Entwickler Team wirklich wissen, welche Funktion ein neues Feature am Ende erfüllen soll, wenn es bei der Discovery nicht beteiligt war? Wo soll das gemeinsame Verständnis für die fachlichen Anforderungen entstehen? Wie kann so Exzellenz entstehen und kann ein Team echt selbstorganisiert sein, wenn es vorgeschriebene Tickets vom Product Owner bekommt?
Vor diesem Hintergrund haben wir in unserem Scrum Team vor einigen Monaten ein Experiment gestartet, dessen Ergebnisse ich hier teilen möchte.
Ausgangssituation:
Unser Scrum Team besteht mittlerweile aus sieben Entwicklern, einem Product Owner und einem Scrum Master. Bis vor einigen Monaten wurden die fachlichen Anforderung meist sehr oberflächlich vom Product Owner übergeben und von einem Proxy PO (einem der Entwickler) analysiert und in kleineren Stories ausformuliert. In einem gemeinsamen Refinement Termin zwischen PO und Dev Team wurden dann die Details vorgestellt. Dies funktionierte oft recht gut, warum also ändern?
Tatsächlich äußerte das Dev Team zunehmend den Wunsch, mehr an der Findung und Formulierung der Anforderungen beteiligt zu werden, um ein gemeinsames Verständnis für die Arbeit und das Produkt entwickeln zu können und somit letztendlich schneller noch bessere Inkremente liefern zu können.
Das erste Experiment:
In einer Retrospektive zu diesem Thema beschlossen wir, künftig neue Themen in rotierenden 2-er Gruppen zu “refinen”. Dieses Experiment dauerte einige Wochen.
Learnings:
Die Vorbereitung von kleineren Themen in 2-er Gruppen funktionierte gut und entlastete gleichzeitig den gemeinsamen Refinement Termin mit dem PO etwas von technischen Detaildiskussionen. Das Scrum Team nutzte den Refinement Termin nun hauptsächlich für echte Produktdiskussionen mit dem PO.
Gleichzeitig war zu beobachten, dass für die Detailplannings weniger Zeit benötigt wurde und bei Bearbeitung der Stories im Sprint die notwendige Information meist bereits an richtiger Stelle vorhanden war und im Refinement jeder Entwickler bereits über die Story diskutiert hat.
Dennoch schien diese Herangehensweise für große neue Themenblöcke noch nicht optimal.
Das zweite Experiment:
Wir beschlossen, dass wir für größere neue Themen zunächst einen Workshop benötigen, um gemeinsames Verständnis zu schaffen. Außerdem schien es hilfreich, wenn das Erstkonzept großer Themen mit allen gemeinsam vorgestellt und diskutiert wird, sowie der erste Storyschnitt erfolgt, bevor die weitere Ausarbeitung zurück in Kleingruppen geht. Auf diese Art und Weise haben alle sehr früh die Möglichkeit, in neue Themen eingebunden zu werden und rechtzeitig kritische Fragen zu stellen bzw. das Konzept mitzugestalten. Unser momentaner Prozess ist im Schaubild dargestellt:
Learnings:
Es hat sich bewährt, große Themen zunächst gemeinsam und anschließend in kleineren Gruppen anzugehen. Die ersten Storyschnitte und Magic Estimations helfen dem PO, die Größe und Komplexität besser einschätzen zu können. Sie helfen dem Dev Team, ein gemeinsames Verständnis dafür zu entwickeln, was in den einzelnen Stories enthalten sein könnte und wo noch offene Fragen sind. Letztendlich ist es ja die Diskussion im Team, worauf es wirklich ankommt.
Ein weiteres wichtiges Learning ist, dass das detaillierte Refinement von Stories nicht allzu lange im Voraus stattfinden sollte. Es reicht aus, wenn die nächsten 1-2 Sprints vorbereitet sind. Dies minimiert einerseits das Risiko, Zeit in etwas zu investieren, was obsolet wird. Andererseits bleiben die geführten Diskussionen und getroffenen Entscheidungen im Gedächtnis und müssen nicht ein weiteres Mal aufgefrischt werden.
Eine weitere Verbesserung wäre, wenn die Entwickler wirklich mit den Stakeholdern sprechen und deren Probleme, Wünsche und Anforderungen aufnehmen könnten. Diese Stakeholder würden im Optimalfall dann auch bei den Sprint Reviews wertvolles Feedback zum Inkrement geben. Diese Optimierung liegt für uns momentan noch ungewiss in der Zukunft. Dementsprechend haben wir noch einen Weg vor uns bis zur vollständigen Einbindung des Entwicklerteams in die Product Discovery. Außerdem braucht das natürliche und automatische Bilden von rotierenden 2er-Gruppen noch etwas Zeit, sich einzuspielen.
Was bedeutet das für das Development Team?
Sie haben die Chance, echt am Produkt beteiligt zu sein und die Anforderungen mit zu entwickeln und gemeinsam zu verstehen. Auch das kritische Hinterfragen von Requirements ist ein essenzieller Qualitätsfaktor für das Produkt, da die Entwickler diejenigen sind, die es gebaut haben und weiterhin bauen werden. Nicht zuletzt hat dies auch Einfluss auf die intrinsische Motivation.
Es ist zu beobachten, dass noch vor der eigentlichen Entwicklung im Sprint das Verständnis für neue Anforderungen und das Endprodukt wächst. Kritische offene Punkte, Fragen und Abhängigkeiten können so rechtzeitig identifiziert und adressiert werden.
Was bedeutet das für den Product Owner?
Der Product Owner hat die Chance, sieben kompetente Experten in die Produktfindung mit einzubeziehen und wertvolles Feedback zu einem sehr frühen Zeitpunkt zu bekommen. Dies reduziert Risiko und Verschwendung. Der hier beschriebene Refinement-Prozess ist eine Vorbedingung dafür, dass sich das gesamte Dev Team zu diesen Experten entwickeln kann. Denn nur dann kommt man zu einem Punkt, wo sich jeder mit dem Gesamtprodukt und den Anforderungen beschäftigt. Der PO bekommt dadurch ein qualitativ hochwertiges Produkt und die Möglichkeit, mit den Entwicklern echte Produktdiskussionen zu führen.