Ein Produktteam kann gelegentlich mit Aufträgen überlastest sein, aber auch unterlastet oder es möchte auch mal neue Features für ein anderes Produkt implementieren. In diesem Falle kann der Backlog skaliert werden. Konkret bedeutet dies, dass der Backlog nicht nur für ein Produkt verwaltet wird, sondern für eine Produkte-Gruppe. Ein wichtiger Erfolgsfaktor hierzu ist eine gute Priorisierung.
Wie in Abbildung 1 dargestellt, stellen so mehrere Product Owner (PO) ihre Aufträge in einen gemeinsamen Backlog. Um eine gute Priorisierung der Backlog-Einträge über mehrere Produkte sicherzustellen, bietet sich die WSJF-Methode an. Dies ergibt eine erste Priorisierung. In der Realität ist es einerseits nicht immer einfach, ein klares Business Value zu bestimmen. Oder POs tendieren dazu, ein überhöhtes Business Value anzugeben, um ihre Features möglichst schnell zur Umsetzung zu bekommen. Zur Unterstützung stehen ergänzend der Business Value Poker oder Priority-Poker als Hilfsmittel zur Verfügung. Nicht zu vergessen sind dabei etwaige Abhängigkeiten untereinander mitzuberücksichtigen.
Abbildung 1: Skalierter Backlog
Die Teams ziehen dann nach einer festgelegten Methodik Aufträge aus dem gemeinsamen Backlog. Trotz allem werden gewisse Aufträge wohl immer noch durch ein spezifisches Team umgesetzt. Denn auch in einer agilen Organisation wird es stets eine gewisse Spezialisierung geben.
Eine wichtige Grundvoraussetzung ist eine Transparenz über die notwendigen und verfügbaren Kompetenzen. Der PO beschreibt die notwendigen fachlichen und technologischen Kompetenzen, um sein Produkt zu (weiter-)entwickeln. Die Teams legen ihre vorhandenen Kompetenzen ebenfalls offen und welche weiteren Interessen zur Weiterentwicklung und Ausbau von Fähigkeiten bestehen. Sinnvoll ist den Austausch unter den Teams möglichst zu fördern.
Empfehlenswert ist den Pull-Mechanismus anzuwenden, d.h. dass die Teams die Aufträge ziehen. Und auch zuzulassen, wenn ein Team einen Auftrag zieht für welchen ihre Fähigkeiten noch nicht vollständig ausreichen. In der Praxis tendieren POs nämlich dazu, die Aufträge denjenigen Teams zuzuspielen – also nach dem Push-Mechanismus – von welchen sie wissen, dass sie über die benötigten Fähigkeiten verfügen. Doch dies ist oftmals kurzfristig gedacht. Denn dieses Konzept ermöglicht eine breite Abstützung des Wissens und ermöglicht Alternativen im Falle von überfüllter Auftragslage.
Kennst du jemanden, der auch von diesem Blog profitieren möchte? Dann leite diesen Blog einfach weiter.
