Ein Scrum Team und viele kleine Produkte – so funktioniert es

In meinem Blog “Ein Scrum Team und viele kleine Produkte – Widerspruch oder Dream-Team?" habe ich die Herausforderungen vorgestellt, vor die ein Team in dieser Konstellation gestellt wird. Wie versprochen möchte ich euch nun aufzeigen, wie ein solches Setup tatsächlich funktionieren kann.

Vielen Dank für die Rückmeldungen, die ich auf den ersten Artikel erhalten habe. Sie zeigen, dass euch diese Szenarien auch nicht fremd, sondern häufiger anzutreffen sind. 

Damit besteht aber auch die Notwendigkeit, sinnvolle Lösungen zu finden, um mit dieser Konstellation – ein Scrum Team kümmert sich um mehrere Produkte – umgehen zu können. Die ideale Lösung, die wir im letzten Artikel angeschaut hatten, pro Produkt ein eigenes Scrum Team aufzustellen, ist meist nicht realistisch. Entweder ist der Entwicklungsumfang oder Anzahl zur Verfügung stehender Entwickler zu klein. Es braucht also andere Lösungen.

Schauen wir uns die zwei Szenarien nochmals an.

Ein Dev-Team – mehrere Product Owner

Wenn sich mehrere POs ein Scrum-Team teilen, stellt sich die Frage, wer bestimmt, was ins Sprint Backlog kommt. Jeder PO priorisiert das Product Backlog für “sein” Produkt. Aber wie funktioniert es mit der Priorisierung der einzelnen Produkte untereinander? 

Wenn es für die relative Priorisierung keinen definierten Prozess gibt, wird die Verantwortung dafür auf das Scrum Team abgeschoben. Die Erwartung, dass die Teammitglieder so tief mit der Firmen-Strategie und den Markt-Bedürfnissen vertraut sind, um diese Priorisierung darauf basierend vornehmen zu können, halte ich für sehr unrealistisch. 

In meiner Erfahrung priorisiert in so einer Situation dann entweder ein Scrum Master oder Team Lead die Aufgaben (nein, Scrum ist das nicht mehr wirklich) oder es wird die Rolle eines Proxy PO kreiert. Diese neue Rolle habe ich auch schon unter den Bezeichnungen IT PO oder technischer PO erlebt. Allerdings ist das dann ein Product Owner ohne echte Ownership, ein reiner Durchlauferhitzer, der aber weder Inhalte noch Prioritäten selbst festlegen kann. 

Aus meiner Erfahrung kommen dann Priorisierungs-Kriterien zum Tragen, wie

• LiFo (= Last in, first out; Wer als letzter am Schreibtisch des SM/Team Leads/Proxy POs gestanden hat, dessen Arbeit kommt in den nächsten Sprint)
• HIPPO (= Highest Paid Person’s Opinion; die Lieblingsthemen des Abteilungsleiters o.ä. bekommen die höchste Priorität)
• WOLF (= Works On Latest Fire; Dinge bleiben liegen, bis es wirklich brennt, man reagiert nur noch und rennt von Notfall zu Notfall) 

Fazit: ohne flankierende Prozess-Erweiterungen kann das unmöglich auf Dauer funktionieren.

Ein Dev-Team – ein PO und viele Stakeholder

Falls dieser PO die Kompetenz hat, die relativen Prioritäten der Produkte selbst festzulegen - natürlich im Einklang mit der Firmenstrategie - würde diese Konstellation theoretisch sogar funktionieren. Die Stakeholder müssen diese Entscheidungen akzeptieren, solange die Strategie sich nicht ändert. 

Die Realität sieht nur leider meist anders aus. Ein PO hat schon bei einem Produkt eine beeindruckende Vielzahl von Aufgaben: Stakeholder-Management, Bedürfnis-Analyse im Markt, Definition von Epics und User Stories und vieles mehr. Ist er nun für mehrere, wenn auch kleine Produkte zuständig, vergrössert sich dieser Berg noch weiter, da die einzelnen Aufgaben nicht unbedingt mit der Grösse des Produktes skaliert. Eine anspruchsvolle Rolle wird damit zu einer kaum zu bewältigenden Herausforderung. Abgesehen von der Machbarkeit ist es in der Praxis eher die Ausnahme, dass ein PO die Prioritäten verschiedener Produkte untereinander festlegen darf.Und damit haben wir fast die gleiche Situation wie im ersten Szenario. Hier hat sich das Problem nur vom Scrum Team (und dem Proxy PO) hin zu dem “richtigen PO“ verschoben. Dieser “richtige PO“ wird auch gerne Business oder fachlicher PO genannt. Die verwendeten Priorisierungs-Methoden dürften damit ebenfalls die gleichen bleiben. 

Prozess-Anpassungen, die das Problem lösen

Damit unser Szenario mit dem einen Scrum Team und mehreren Produkten funktionieren kann, brauchen wir eine Mischlösung aus den beiden vorgestellten Konstellationen. Wie müssen wir also die bekannten Elemente aus Scrum anpassen?

Dev Team & Scrum Master
Für die Inhaber dieser beiden Rollen ändert sich nichts.

PO
Für jedes der Produkte ist weiterhin ein PO zuständig - mit allen Aufgaben und Verantwortlichkeiten. Er pflegt – d.h. refined und priorisiert - auch das Produkt BL seines Produktes, das nur die Backlog Items für dieses Produkt enthält. Der einzige Unterschied ist, dass dieser PO nicht alleinigen Zugriff auf den Rest des Scrum Teams hat. In anderen Worten, das Sprint Backlog des Scrum Teams wird nicht nur aus dem Produkt Backlog dieses POs gefüllt.

Priorisierungs-Meeting & Team-Backlog
Nun sind wir an dem Punkt, an dem die gewohnten Vorgehen erweitert werden müssen.

Wie wird also nun das Sprint Backlog des Teams gefüllt?  

Es braucht einen Prozess, in dem die Prioritäten der einzelnen Produkte untereinander festgelegt werden – und damit Klarheit, welcher PO das Recht hat, das Sprint Backlog mit seinen Backlog Items zu füllen. Natürlich könnte man diese Diskussion in jedem Sprint Planning führen und jeweils für jeden Sprint neu verhandeln, was ins Sprint Backlog kommt. Allerdings ist das recht ineffizient, da im Sprint Planning immer das gesamte Team anwesend ist, diese Diskussion aber mehrheitlich zwischen den POs stattfindet. Daher empfehle ich ein Zwischengefäss. Das heisst, ein Team-Backlog, das einen gewissen Vorrat an priorisierter Items enthält. So kann im Planning rein auf die Kapazitäten geschaut werden und einfach die am höchsten priorisierten Items in den Sprint gezogen werden. Idealerweise enthält dieses Team-Backlog einen Vorrat für 2-3 Sprints – allerdings auch nicht mehr als Arbeit für ca. 3 Monate, da es sonst unübersichtlich wird. Das hilft auch, klare Erwartungen bei den POs zu bilden - denn was nicht im Team-Backlog ist, wird kaum in den nächsten 3 Monaten erledigt werden. Haben sich die Prioritäten geändert und das Maximum im Team-Backlog ist erreicht, müssen Items wieder zurück in die Produkt Backlogs, um durch die höher priorisierten ersetzt werden zu können. 

Diese Vorbereitung des Arbeits-Backlogs findet in einem neuen Event statt, bei dem die POs der Produkte regelmässig zusammenkommen, die Prioritäten ihrer Produkte untereinander verhandeln und das Team-Backlog des Scrum Teams wieder bis auf das Maximum auffüllen. Je nach Rahmenbedingungen kann man hier noch weitere Abmachungen treffen, wie zum Beispiel fixe Anteile der Team Kapazität pro Produkt. Was genau nötig und sinnvoll ist, muss von Fall zu Fall individuell angeschaut werden.

Nun könnte man einwenden, dass dieses Konstrukt zu kompliziert sei. Ebenso könnte ein gemeinsames Backlog für alle Produkte geführt werden. Jeder PO nutzt dann Sichten auf die sein Produkt betreffenden Items. Es gibt aber diverse praktische Gründe, aus denen ich davon abrate. Ihre Diskussion würde aber den Rahmen dieses Artikels sprengen. Ich gehe gerne, z.B. im direkten Gespräch, näher drauf ein.

Team-Backlog Owner
Idealerweise gibt es einen Owner dieses Team-Backlogs. Nun könnte man sagen, dass das ja genau der “Proxy PO” oder “IT PO” von weiter oben wäre. Ich bin kein grosser Fan davon, diese Bezeichnung für die Rolle des Backlog Owners zu verwenden, da diese Namen falsche Erwartungen wecken. Der Inhaber dieser Rolle ist nicht der Owner des Produkts und kann meist nur Stories und Prioritäten entgegennehmen, aber nicht in Eigenverantwortung selbst definieren. Worüber der Inhaber dieser Rolle aber tatsächlich die Hoheit hat, ist das Team-Backlog. Es gehört zu den Aufgaben dieser Rolle, dafür zu sorgen, dass sich die POs bezüglich Priorisierung absprechen und das Team-Backlog regelmässig aufgefüllt wird. Er muss Sorge tragen, dass nur ausgearbeitete und schätzbare Items mit klar definierten Inhalten ihren Weg ins Team-Backlog finden. Ausserdem vertritt er die Interessen des Scrum Teams, um die technische Sicht auf die Aufgaben in die Planung einzubringen. Insgesamt ist der meiner Meinung nach am besten passende Name für die Rolle “Team Backlog Owner” (BO). 

Wie klingt dieses Vorgehen für euch? Falls ihr vor der Herausforderung „Ein Scrum Team, viele kleine Produkte“ steht - habt ihr den Eindruck, dass das vorgestellte Vorgehen die Lösung sein kann? Ich freue mich auf eure Rückmeldungen in den Kommentaren oder im direkten Kontakt (Agile Coach: Viola Ehrensperger - SwissQ | part of Xebia).