Wie können Unternehmen agiler arbeiten?
„Delegation of product owner responsibilities continues the deep divide between development and its customers. My concept of the Scrum Master was that they were going to bridge the divide. The Scrum Master would to teach the business how to be agile by fulfilling the role of the Product Owner. The Scrum Master was going to help the PO understand how to take advantage of opportunities, to optimize value, and how to collaborate with the team. In no way did I envision the Product Owner becoming a business analyst that was responsible for requirements engineering.“
Je weiter Kunden und Produktentwicklung auseinanderdriften, desto weniger agil kann ein Unternehmen sein.
Das liegt daran, dass Entscheidungen nicht dort getroffen werden, wo die Probleme auftreten. Nach Ken Schwaber liegt der Schlüssel zur Agilität eines Unternehmens in der Rolle des Product Owners. Da Scrum Master die Agilität im Unternehmen verantworten, ist es ihre Aufgabe, Produktmanagern, Kunden und Managern die Product-Owner-Verantwortung zu erklären. Somit ist ein Indikator für die Agilität im Unternehmen das Verständnis über die Rolle des Product Owners im Unternehmen.
In den vergangenen Jahren habe ich in vielen Scrum Teams und Unternehmen gearbeitet und die Anzeichen dafür, dass die Rolle des Product Owners (noch) nicht verstanden wurde, sahen stets ähnlich aus/waren immer die gleichen. Die fünf häufigsten stelle ich dir jetzt vor:
Anzeichen 1: Der Scrum Master ist der Product Owner
Ab 2015 arbeitete ich bei der B/S/H als Product Owner.
Nach dem ersten Sprint in unserem neuen Team waren die User Stories entweder nicht abgeschlossen oder die Umsetzung entsprach nicht meinen Qualitätsansprüchen. Mir war bewusst, dass wir das im nächsten Sprint verbessern mussten. Der beste Weg, um damit zu beginnen, war die Retrospektive. Da wir zu Beginn noch keinen Scrum Master im Team hatten, übernahm ich die Verantwortung des Scrum Master und moderierte den Termin.
Bis zum Ende der Retrospektive konnten wir uns jedoch auf keine Verbesserung einigen.
Als Product Owner war mir wichtig, dass wir im nächsten Sprint zwingend etwas Nützliches bereitstellen würden, was den Ansprüchen der Nutzer genügt. Als Scrum Master war mir wichtig, eine Atmosphäre zu schaffen, in der wir bestehende Probleme offen und respektvoll ansprechen konnten. Beides zu vereinen, war mir unmöglich. Seit dieser Zeit bin ich fest überzeugt, dass Scrum Master nicht Product Owner sein sollten. Der Fokus und Gewohnheiten sind einfach zu verschieden.
Scrum Master konzentrieren sich auf die stetige Verbesserung der Entwicklungspraxis und Zusammenarbeit, während Product Owner den Wert im Blick haben, den die Arbeit des Teams verspricht. Wenn beides in einer Person vereint wird, besteht die Gefahr, dass keines von beiden die verdiente/notwendige Aufmerksamkeit bekommt.
Wenn du mehr über die Lektion aus meiner Zeit als Product Owner lesen willst, dann wirf einen Blick auf: „5 Lektionen, die ich im ersten Jahr als Product Owner gelernt habe, die Dir viel Zeit und Frust ersparen können“
Anzeichen 2: Der Product Owner stellt Anforderungen
Manchmal übersetzen Product Owner ein Geschäftsproblem in Anforderungen an das Produkt.
Allerdings birgt dieses Vorgehen viele Probleme: Produktentwicklung ist unberechenbar, es werden Projekte auf diesem Weg also oft verspätet und nur durch Überschreitung des Budgets abgeschlossen. Werden geschäftliche Anforderungen höher priorisiert als Kundenwünsche, dann müssen Teams nach der Auslieferung des Produkts feststellen, dass die Nutzer von dem, was die Teammitglieder entwickelt haben, nicht begeistert sind. Spielt der Product Owner nur die Rolle des Übersetzers, dann wird viel Zeit und Geld verschwendet.
Scrum Teams, die so arbeiten, werden als „Delivery Teams“ oder „Feature Factory“ bezeichnet.
Nach Ralph Jocham, dem Autor von „Der professionelle Product Owner“, sollten Product Owner nicht Anforderungskataloge erstellen, sondern eine umfangreiche To-do-Liste für das Produkt. Wenn du an deine eigene To-do-Liste denkst, was findest du da? Hast du dort jedes Detail erfasst oder sind es nur kurze Notizen, damit du wichtige Dinge oder Gespräche nicht vergisst? Ralph wirbt dafür, dass der Product Backlog mit der Absicht erstellt werden sollte, nicht zu vergessen, die richtigen Fragen bei der Produktentwicklung zu stellen.
Product Owner sind keine Übersetzer, sondern Entdecker jener Dinge, die für das Produkt wertvoll sein könnten.
Anzeichen 3: Der Product Backlog besteht nur aus User Stories
Hast du dich schon einmal gefragt, warum der Scrum Guide von Product-Backlog-Einträgen spricht und nicht von User Stories?
Die Antwort ist einfach. Nicht alles ist eine User Story. Nicht alle Einträge auf der „To-do-Liste“ für das Produkt stammen von einem Nutzer. Wird aber jeder Eintrag fälschlicher als User Story betitelt, so erweckt er diesen Anschein. Das wiederum reduziert das gemeinsame Verständnis von der noch zu erledigenden Arbeit im Scrum Team. Es ist dann nicht mehr ersichtlich, von wem eine Idee stammt. Handelt es sich um eine Geschichte, die uns ein Nutzer über die Verwendungen des Produkts in einem Interview erzählt hat, oder ist es eine Anforderung des Unternehmens?
Hier einige Arten von Einträgen im Product Backlog:
- Feature-Anfragen: „Ich benötige eine Funktion, um alle Verkaufstransaktionen als Tabelle zu exportieren.“
- Experimente: Wir wollen das Preismodell von der Einmalzahlung auf ein Abo-Modell umstellen. Wie können wir testen, ob die Nutzer diese Umstellung akzeptieren werden?
- Nichtfunktionale Anforderungen: Statt 3.000 sollten 30.000 Nutzer gleichzeitig das System verwenden können.
- Anwendungsfälle: Der Tempomat regelt die vom Fahrer eingestellte Geschwindigkeit in Abhängigkeit der Verkehrslage.
- Fehler: Der Kundensupport hat berichtet, dass Nutzer ihr Passwort nicht mehr eigenständig zurücksetzen können.
Als Scrum Master solltest du dem Product Owner helfen, den passenden Typ für die Arbeit am Produkt zu wählen. Dies hält der Scrum Guide im Abschnitt über Refinement fest:
„Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Größe ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.“
Da sich die Attribute nach Umfeld, in dem das Team operiert, ändern, reduziert das alleinige Verwenden von User Stories die Transparenz des Product Backlogs.
Wenn du mehr über User Stories erfahren willst, dann lies gerne diesen Artikel: „3 schockierende Probleme mit User Stories, die jeder Product Owner unbedingt vermeiden sollte“
Anzeichen 4: Nur der Product Owner verwaltet den Product Backlog
Wenn wir die letzten beiden Anzeichen zusammenfassen, dann können wir sagen:
Der Product Backlog sollte kein reines Anforderungsdokument sein und nicht ausschließlich aus User Stories bestehen. Wir sollten den Product Backlog als To-do-Liste für das Produkt sehen, die Fragen enthält, welche wir beim Entdecken neuer Merkmale des Produkts noch beantwortet sollten.
Somit ist der Product Backlog weniger ein Werkzeug zur Dokumentation als vielmehr ein Werkzeug zur Zusammenarbeit.
Damit die Zusammenarbeit funktionieren kann, gilt es, diesen Abschnitt des Scrum Guides aufmerksam zu lesen:
„Der Product Owner ist auch für ein effektives Product-Backlog-Management ergebnisverantwortlich, das Folgendes umfasst:
- das Produktziel zu entwickeln und explizit zu kommunizieren;
- die Product-Backlog-Einträge zu erstellen und klar zu kommunizieren;
- die Reihenfolge der Product-Backlog-Einträge festzulegen und
- sicherzustellen, dass der Product Backlog transparent und sichtbar ist sowie verstanden wurde.
Der Product Owner kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der Product Owner ergebnisverantwortlich.“
Wichtig ist der vorletzte Satz. Der Product Owner muss diese Arbeiten nicht selbst durchführen. Dieser Satz ermöglicht es, den Product Backlog als ein Werkzeug zur Zusammenarbeit zu verwenden. Betrachten wir den zweiten Aufzählungspunkt, dann heißt es genauer: Entwickler im Scrum Team und Product Owner können gemeinsam die Einträge im Product Backlog erarbeiten. Meiner Erfahrung nach resultiert dies in einem gemeinsamen Verständnis darüber, was das Produkt in Zukunft enthalten soll.
Fehlt dies gemeinsames Verständnis, dann fällt es Scrum Teams schwer, schnell Entscheidungen zu treffen.
Anzeichen 5: Der Product Owner nimmt die Arbeit des Scrum Teams an oder lehnt sie ab
Es gibt einen Grund, warum Akzeptanzkriterien kein Bestandteil von Scrum sind.
Werden Akzeptanzkriterien falsch angewendet, dann wird damit eine Auftraggeber- und Auftragnehmer-Beziehung im Scrum Team ausgedrückt. Dies führt zur weiteren Aufspaltung zwischen IT und Business und reduziert somit die Agilität im Unternehmen.
Da dieses Vorgehen weitverbreitet ist, wurde es in der letzten Aktualisierung des Scrum Guides explizit thematisiert. Mit der Einführung eines Produktziels und der Reduktion auf nunmehr ein (Scrum) Team, soll dieser Aufspaltung entgegengewirkt werden:
„Ein Team, fokussiert auf ein Produkt
Ziel war es, das Konzept eines separaten Teams innerhalb eines Teams zu beseitigen, das zu einem ‚Stellvertretenden‘- oder ‚Wir und sie‘-Verhalten zwischen dem PO- und dem Dev-Team geführt hat. Es gibt jetzt nur noch ein Scrum Team, das sich auf dasselbe Ziel fokussiert und drei verschiedene Ergebnisverantwortlichkeiten hat: PO, SM und Developer.“
Somit sollte die Abnahme von User Stories im Sprint Review ein Relikt der Vergangenheit darstellen. Ist dies nicht der Fall, dann solltest du als Scrum Master handeln.
Bist du breit zu handeln?
Wenn du eines dieser Anzeichen in deinem Scrum Team bemerkt hast und nach Unterstützung bei der Behebung suchst, dann habe ich ein Angebot für dich: das „PSPO-A“-Training.
Dort erfährst du, wie du
- anstatt User Stories zu schreiben, testbare Hypothesen erarbeitest,
- anstatt mit Anforderungsdokumenten zu arbeiten, die Zusammenarbeit zwischen Entwicklern, Product Owner und Stakeholdern mit einer Product-Wall produktfokussiert gestalten kannst,
- mit Produktmetriken der Auftraggeber- und Auftragnehmer-Beziehung entfliehst und den Erfolg des Produkts und somit des gesamten Scrum Teams quantifizierbar machen kannst.
Kurzum: Im Training siehst du, wie durch agiles Produktmanagement ein Team eine Idee in ein Produktfeature verwandelt, was Nutzer begeistert und wie Product Ownership die Rolle des Dirigenten bei dieser Zusammenarbeit bedeutet.
Nach diesem Training kannst du deinen Product Owner besser unterstützen und dabei helfen, dass IT und Business nicht auseinanderdriften.
Das Training findet in München in wenigen Wochen statt und ich gebe es zusammen mit Peter Götz. Peter ist Product Owner bei der Kohlekumpels GmbH und erfahrener Scrum Trainer. Hier kannst du dich anmelden.