• Agile Organisation

Datum

29. Jul 2021

Ein Scrum Team, mehrere Produkte - so kann es funktionieren.

Die Spielregeln im Scrum Guide besagen, dass jedes Produkt über ein Product Backlog verfügt, welches durch einen Product Owner gemanaged wird. Doch was passiert, wenn innerhalb einer Organisation mehrere Produkte mit eigenen Product Backlogs und Product Owner vom gleichen Team umgesetzt werden?

Scrum ist ein einfaches Framework, mit welchem inkrementell und iterativ Lösungen für komplexe Probleme in einer schnelllebigen Welt entwickelt werden. Die Spielregeln im Scrum Guide besagen, dass jedes Produkt über ein Product Backlog verfügt, welches durch einen Product Owner “gemanaged” wird. Dies bedeutet konkret:

  • Die Entwicklung & Kommunikation des entsprechenden Produkte-Ziels

  • Die Erstellung und Priorisierung der Product Backlog Items und deren Kommunikation

  • Die Sicherstellung, dass das Product Backlog transparent, sichtbar und verstanden wird

Doch was passiert, wenn innerhalb einer Organisation mehrere Produkte mit eigenen Product Backlogs und Product Ownern vom gleichen Team umgesetzt werden?

Da jeder Product Owner ausschliesslich rechenschaftspflichtig für die Wertmaximierung seines Produkts und nicht des ganzen Unternehmens ist, könnte dies zu Zielkonflikten oder gar wirtschaftlichen Fehlentscheidungen führen.

Im avega Solution Atelier standen wir vor genau dieser Herausforderung - plötzlich kamen mehrere Produkte, Product Backlogs und Product Owner dazu, haben aber nur ein interdisziplinäres Team, welches alle Ideen umsetzt. Damit der Fokus auf die richtigen und wertvollsten Themen gelegt werden kann, haben wir eine übergreifende Product Owner Accountability (Overall Product Owner) eingeführt, welche die Steuerung des Portfolios und die Wertmaximierung des Teams sicherstellt.

Der Overall Product Owner bestimmt basierend auf strategischen Stossrichtungen, aktueller Auftragslage und herrschenden Markteinflüssen das Portfolio und die Ressourcenallokation für die nächsten Sprints. Aus den einzelnen Product Backlogs werden diejenigen Items, welche demnächst umgesetzt werden sollen, herausgenommen und in einem temporären Backlog konsolidiert. In regelmässigen Meetings füllt, aktualisiert und priorisiert der Overall Product Owner gemeinsam mit den Product Ownern das temporäre Backlog, welches dann im Sprint Planning als Quelle für das Sprint Backlog dient. Die Sprint Backlog Items werden wie gewohnt mit Scrum, dessen Werten, Prinzipien und Events umgesetzt.

In einem Workshop wurden gemeinsam das Zusammenarbeitsmodell und die Aufgaben der Product Owner und des Overall Product Owners bei avega erarbeitet:

Scrum Zyklen mit mehreren Produkt-Backlogs
Aufgaben Product OwnerAufgaben Overall Product Owner
  • Ist rechenschaftspflichtig über die Wertmaximierung des Produktes.

  • Schaut, dass sein Product Backlog priorisiert und in gutem Zustand ist (wertvolle und gut definierte Inhalte, welche bereit zur Umsetzung sind, oben. Ideen und weniger gut definierte Inhalte unten.)

  • Hat eine klare Vision von seinem Produkt.

  • Hat eine Produkte-Roadmap (Vision, Priorisierung und validierten Zeitplan), welche folgende Punkte berücksichtigt:

    • Kundenerwartungen

    • Produkt-Ziele (Meilensteine)

    • Lieferobjekte

    • Kapazitäten, strategische Kapazitätsplanung

    • Budgetierung

  • Ist rechenschaftspflichtig für die strategische Wertmaximierung aller Produkte.

  • Stellt sicher, dass eine strategische Kapazitätsplanung existiert und eingehalten wird.

  • Koordiniert die verschiedenen POs, wo nötig.

Seit der Einführung dieses Zusammenarbeitsmodells und der Definition der Aufgaben, sind der Ablauf und die Planungmeetings viel strukturierter und effizienter. Durch die Transparenz des Portfolios und die strategische Ressourcenallokation sind die übergreifenden Prioritäten klar. Die Product Owner wissen wie viel Kapazität in den nächsten Iterationen für ihr Produkt aufgewendet werden kann und können Backlog und Roadmap entsprechend bewirtschaften.

Natürlich stellen sich uns im aktuellen Setup auch Herausforderungen. Aufgrund der Tatsache, dass das Team an mehreren Produkten arbeitet, ist es teilweise schwierig den Fokus zu halten und ein Sprintziel zu definieren. Weiter arbeiten oftmals die gleichen Personen an den selben Produkten, was zu weniger Berührungspunkten im Team und zu Statusmeetings, an Stelle der Daily Scrums, führt.

Verbesserung bringt hier eine produktbezogene Sprint Fokussierung. Dabei adressieren das Sprintziel und die Mehrzahl der selektieren Product Backlog Items im Sprint nur ein Produkt. Die Ressourcenallokation ist jetzt nicht mehr konstant sondern mittelt sich über mehrere Sprints (z.B. Gewichtung 2/3 für Produkt A und 1/3 Produkt B = 1. + 2. Sprint Fokus Produkt A und 3. Sprint Fokus Produkt B). So können die Entwickler zusammen an einem gemeinsamen Sprintziel arbeiten und mehr voneinander profitieren. Gleichzeitig können die Product Owner der Produkte, welche gerade nicht den Sprintfokus geniessen, die Zeit nutzen, um mit den Stakehodern zusammen zu arbeiten und ihr Product Backlog in einen guten Zustand zu bringen. Somit können sie durchstarten, wenn sie innerhalb eines Sprints die geballte Umsetzungspower erhalten.

Im Sinne von “Inspect” und “Adapt”, decken wir Suboptimalitäten auf, entwickeln Lösungen und testen diese. Wir lernen, probieren und verbessern. 😄

Neugierig was das Solution Atelier bereits alles umgesetzt hat? Hier findest du die Werke.