Scrum-Puristen argumentieren, dass man nicht mehrere Product Owner gleichzeitig haben kann. Bei mehreren Product Ownern wird die Rechenschaftspflicht zu einem Problem. Mit mehreren Entwicklungsteams bietet das LeSS Huge Framework eine bequeme Lösung. Erfahren Sie mehr darüber.
A QUICK SUMMARY – FOR THE BUSY ONES
TABLE OF CONTENTS
Das Scrum-Leitfaden beschreibt den Product Owner als die alleinige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Mit anderen Worten, der Product Owner definiert, was das Entwicklungsteam in welcher Reihenfolge bauen soll.
Die Philosophie „weniger ist mehr“ gilt sicherlich für Product Owner, aber es gibt viele Situationen, in denen es unvermeidlich ist, mehrere Product Owner zu haben, und es ist von größter Bedeutung zu wissen, wie man mit ihnen umgeht.
<blockquote><p>„Oft arbeiten mehrere Scrum-Teams zusammen an demselben Produkt. Ein Product Backlog wird verwendet, um die bevorstehende Arbeit am Produkt zu beschreiben „,</p> so <p>der Scrum</p></blockquote> Guide
Ein Product Backlog bedeutet einen Product Owner, weshalb Scrum Puristen argumentieren, dass man nicht mehrere Product Owner haben kann und Scrum gleichzeitig.
Laut dem Scrum Guide:
<blockquote><p>„Der Product Owner ist eine Person, kein Ausschuss.“</p></blockquote>
Der Scrum Guide ist diesbezüglich sehr klar, da Ausschüsse dafür bekannt sind, die Transparenz zu verringern und die Überprüfung und Anpassung drastisch zu verlangsamen.
<blockquote><p>„Es ist sehr schwierig, mehreren Stimmen zuzuhören“,</p> <p>— Rebecca Jones, Boost Scrum Master für die neuseeländische Nationalbibliothek</p>.</blockquote>
Bei mehreren Product Ownern wird die Rechenschaftspflicht zu einem Problem. Wenn sich niemand persönlich dafür verantwortlich fühlt, Termine einzuhalten und wichtige Meilensteine zu erreichen, wird der Produktrückstand oft größer und größer, ohne dass ein einziges Genick zu ringen ist. Darüber hinaus erfordert die Anwesenheit mehrerer Product Owner eine komplexe Koordination und Abstimmung, und selbst die kleinste Fehlausrichtung der Prioritäten kann einzelne Teams daran hindern, ihre Arbeit zu erledigen.
Die tatsächlichen Bedürfnisse echter Unternehmen, die an echten arbeiten Produkte haben oft Vorrang vor Best Practices.
<blockquote><p>„Wenn wir einen Product Owner hätten, würde er seine ganze Zeit als Product Owner damit verbringen, Geschichten zu kreieren, Geschichten zu dimensionieren und zu verfeinern. Irgendwann hatten sie keine Verbindung mehr zu dem eigentlichen Geschäft, für das sie eigentlich der Product Owner sein sollten. „</p><p>— James Robertson, DigitalNZ</p></blockquote> Systems Manager.
Die Verwaltung komplexer Produkte ist häufig die gemeinsame Aufgabe mehrerer Product Owner. Daher ist es wichtig zu wissen, wie die Produktverantwortung so aufgeteilt werden kann, dass die Transparenz gewahrt wird, die Inspektion erleichtert, die Anpassung verbessert und nicht zu Inkonsistenzen führt.
<blockquote><p>„Solange ein Produkt noch jung ist und noch nicht markttauglich ist — oder kurz davor steht, es zu erreichen — empfehle ich, eine einzige Person für das Produkt verantwortlich zu machen.“</p> <p>„Aber sobald das Produkt erfolgreicher wird und wächst, wenn es mehr Funktionen bietet und umfangreicher wird und mehr Teams für die Entwicklung benötigt, kann eine einzelne Person das Produkt normalerweise nicht mehr verwalten — ohne überarbeitet zu werden</p> oder einige Aufgaben zu vernachlässigen.“ <p>— Roman Pichler, Experte für Produktbesitz.</p></blockquote>
Beispielsweise kann ein Produkt mehrere verschiedene Streams haben, die unterschiedliche Fähigkeiten erfordern, wobei jedem Stream ein Product Owner zugewiesen ist. Manchmal arbeitet ein einzelnes Team an täglichen Updates für mehrere Produkte, von denen jedes seinen eigenen Product Owner hat. Eine Webentwicklungsagentur kann sich für eine Auslagerung entscheiden Entwickler von mobilen Apps um an demselben Produkt zu arbeiten, wodurch mehrere Product Owner erforderlich sind.
Mit mehreren Entwicklungsteams das LeSS Huge Framework bietet eine komfortable Lösung das das Product Backlog in mehrere Anforderungsbereiche aufteilt und jedem einen anderen Area Product Owner zuweist. Anforderungsbereiche sind kundenorientierte Kategorien von Product Backlog-Elementen wie Zuverlässigkeit, Verwaltung, Upgrades, kontinuierliche Integration, Protokolle usw. Area-Backlog-Elemente sind feinkörniger als Product-Backlog-Elemente, die grobkörniger und daher leichter zu handhaben sind.
<blockquote><p>„Ein Area Product Owner ist auf einen kundenorientierten Bereich spezialisiert und fungiert als Product Owner in Bezug auf die Teams für diesen Bereich.“</p> <p>„Ein Area Product Owner erledigt die gleiche Arbeit wie ein Product Owner, jedoch mit einer eingeschränkteren, aber immer noch kundenorientierten Perspektive</p>.“ </blockquote><p>— LeSS Creators auf der offiziellen Website des Frameworks.</p>
Es wird empfohlen, dass ein Area Product Owner mit 2 bis 8 Entwicklungsteams zusammenarbeitet, was in der Standardversion des LeSS-Frameworks empfohlen wird. Ebenso wird empfohlen, dass Entwicklungsteams die Möglichkeit haben, einige Geschichten zwischen ihnen auszutauschen, um die Idee eines gemeinsamen Projekt-Backlogs zu fördern.
Zusätzlich zum LeSS Huge Framework es gibt auch das Scaled Agile Framework, das mit Product Ownern und Team Backlogs anstelle von Area Product Ownern und Area Backlogs und dem Product Manager und dem Program Backlog statt dem Product Owner und dem Product Backlog funktioniert.
<blockquote><p>„Jeder Produktmanager kann in der Regel bis zu vier Product Owner unterstützen, von denen jeder für den Backlog eines oder zweier Agile-Teams verantwortlich sein kann.“</p> <p>„Erfolgreiche Entwicklung ist im Unternehmen zum Teil ein Zahlenspiel. Ohne die richtige Anzahl von Mitarbeitern in den richtigen Rollen werden Engpässe die Geschwindigkeit erheblich einschränken</p>.“ </blockquote><p>— die offizielle Website des LeSS-Frameworks.</p>
Was die Frameworks LeSS Huge und Scaled Agile gemeinsam haben, ist, dass ein Project Backlog genau einem Product Owner zugewiesen wird, unabhängig davon, welche Terminologie verwendet wird. Diese klare Rollenverteilung hilft dabei, die Prioritäten im Unternehmen aufrechtzuerhalten und verhindert das Risiko von Konflikten zwischen verschiedenen Projekten.
Wenn der Umfang der Entwicklung riesig ist und das Management keine andere Wahl hat, als mehrere Entwicklungsteams zu unterstützen, ist es oft am besten, das Project Backlog in mehrere Bereiche aufzuteilen und jedem Bereich genau einen Product Owner zuzuweisen.
Our promise
Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.
Authors
Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.
Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.
Read next
Popular this month
previous article in this collection
It's the first one.
