Product Owner: Motor oder Sollbruchstelle agiler SW-Projekte? (Teil 3)
Dieser Beitrag ist der dritte und letzte Teil unserer Serie „Product Owner: Motor oder Sollbruchstelle agiler SW-Projekte?“ In Teil 1 habe ich beschrieben, warum Softwareprojekte oft (ca. 70%!) scheitern. In Teil 2 ging es um die Frage, warum die immanenten Probleme komplexer Softwareprojekte nicht automatisch verschwinden, wenn man z.B. auf Scrum setzt.
Im letzten Teil sehen wir uns an, was der Product Owner alles kennen und leisten muss. Und schließlich geht es um die für die Besetzung dieser kritischen Rolle entscheidenden Frage, welche Skills erforderlich sind und wie wahrscheinlich es ist, dass sie in einer Person vereint sind.
Mit welchen Artefakten sollte sich der Product Owner beschäftigen?
Selbst die besten Product Owner verlieren leicht den Überblick zwischen den strategischen, konzeptionellen Aspekten eines Softwareprodukts und den Tausenden Details, die bei seiner Umsetzung relevant sind. Selbst wenn ein PO alles im Kopf behalten kann, wird er es schwer haben, dieses Wissen nur mündlich an andere zu vermitteln. Auch das Product backlog alleine taugt dafür nicht. Deshalb sollte ein PO nach meiner Erfahrung mit folgenden Artefakten verschiedener Granularität arbeiten:
- Product statement / Project charter: Beschreibt kurz und prägnant das Nutzenversprechen des Produkts, also was es warum kann sowie relevante Rahmenbedingungen, z.B. finanzieller, organisatorischer und/oder regulatorischer Natur. In der Regel wird der PO dieses Artefakt vom Business Owner / Sponsor erhalten / einfordern oder es mit ihm zusammen entwickeln
- Product vision: Beschreibt die Vision des fertigen Produkts (bzw. relevanter Ausbaustufen). Das sollte typischerweise aus der Sicht der Anwender geschehen. Profitip: Eine buchstäblich greifbare Vision kann z.B. ein fiktiver Verkaufskarton sein, auf dem Nutzen, Highlights und Features des Produkts beworben werden. Platzieren Sie diesen dort, wo sich das Team besonders häufig aufhält (neben der Kaffeemaschine!), um immer wieder vor Augen zu führen, worum es geht
- Story map: Ein Hilfsmittel für die agile Releaseplanung und das Befüllen des Product backlogs. Typischerweise eine Matrix, bei der horizontal die großen Anwendungsfälle aufgelistet sind, die vertikal immer mehr verfeinert werden. In einer solchen Matrix (am besten als physikalische Tafel mit Post-Its o.ä.) kann am besten der Überblick über das System gewonnen und mit Stakeholdern, die ggf. Zielkonflikte haben, diskutiert werden
- Design statement(s): Beschreibt den fachlichen und technischen Entwurf des Produkts. Der PO ist gut beraten, diese Entwürfe mit erfahrenen Entwicklern / Architekten zu erstellen, denen diese Statements später als Leitplanken für die Implementierung dienen. Neben dem fachlichen Entwurf, für den sich z.B. die Methodik Domain-Driven Design anbietet (die übrigens hervorragend parallel zur Erstellung der Story map mit Stakeholdern angewendet werden kann), gehören hier auch solche Entwurfsentscheidungen rein, die IT-strategischer Natur sind, z.B. die Vorgabe, dass statt einer „klassischen“ 3‑tier-Architektur eine besser beherrsch- und erweiterbare Zwiebelarchitektur zu verwenden ist
- Product backlog: Erst dann kommen wir zum zentralen Artefakt des PO, das eigentlich eine Sammlung von Artefakten ist, den sogenannten Backlog items. Diese sind in der Reihenfolge ihrer Umsetzungspriorität sortiert und in der Regel (aber nicht notwendigerweise) in der Form von User Stories formuliert. Im Rahmen des regelmäßigen backlog refinements verfeinert der PO das Backlog, so dass immer ausreichend Items an der Spitze des Backlogs stehen, die formal umsetzungsreif sind. Viele Projekte formulieren dafür eine Checkliste namens DoR (Definition of ready), die analog zur DoD (definition of done) dem PO Orientierung gibt, ob ein Item umsetzungsreif ist (die eigentliche Entscheidung über die Annahme trifft das Team im Sprint Planning)
Die Grafik zeigt das ganze im Überblick:
Ab dem Product backlog setzt dann wieder der etablierte Scrum-Prozess ein. Aber eben erst dann. Es ging ja hier um die anfangs aufgeworfene Frage, wie eigentlich das Backlog entsteht bzw. was der PO alles zu tun hat.
Welche Skills sollte der Product Owner besitzen?
Aus der bis hier erfolgten Konkretisierung der Rolle Product Owner und ihrer Aufgaben, sollte schon deutlich geworden sein, dass sie eine Menge Skills in sich vereinen muss:
- Beraterskills: Der PO ist Berater verschiedener Gruppen mit unterschiedlichen Interessen und Anlagen und muss sie in Richtung des Projekterfolgs führen. Neben entsprechender Erfahrung sind hierfür vor allem diplomatisches Geschick und kommunikative Stärken nötig
- Managementskills: Bei einem agilen Projekt sind unendlich viele Entscheidungen zu treffen, vor allem was jetzt (noch) nicht gemacht wird. Wenn die Rahmenbedingungen vom Sponsor einmal gesetzt sind, ist der PO der Haupt-Entscheidungsträger. Insbesondere muss er auch gute Wünsche und Ideen der Stakeholder, der Entwickler und (das ist am schwierigesten) seiner selbst zurückstellen, wenn sie keinen ausreichenden ROI bringen
- Visionär: Es muss nicht gleich ein Steve Jobs sein, aber der PO ist derjenige, der die Vision des Produkts haben und verfolgen muss
- Technologisches Know-How: Der PO muss ausreichend Know-How haben, um solche Entwurfsentscheidungen zu treffen und mit dem Team diskutieren zu können, die für die IT-strategische Ausrichtung des Produkts relevant sind. Im Umfeld von Webanwendungen gehört dazu, die im Internet gängigen Architekturmuster zu kennen (Hinweis: Das geht weit über monolithische 3‑Tier-Architekturen hinaus), denn wer soll strategische Produktentscheidungen treffen, wenn nicht der PO?
- Herausragende Auffassungs- und Konzeptionsgabe: Die Analyse- und Entwurfsfähigkeiten müssen bei einem PO stärker als bei einem Requirements Engineer, da er sowohl hinsichtlich des Prozesses als auch der Inhalte einen deutlich höheren Bereich abdeckt
- Empathie: Diese Eigenschaft mag überraschen, aber neben dem Verständnis der Ansprechpartner im Projekt muss der PO vor allem Einfühlungsbedürfnis für die Anwender des Produkts haben, um es zu einem vom Benutzer als hilfreich empfundenen machen zu können. Ein erfahrener PO wird aus diesem Grunde auch immer zu User Centered Design neigen, schon in der Produktvision, aber auch bei der Ausarbeitung der einzelnen User Stories
In den seltensten Fällen wird eine Person alle diese Skills in sich in ausreichendem Maße vereinen. Und wenn man keine solche findet? Zwar sieht Scrum aus gutem Grund nur einen PO vor. Bevor das Projekt aber wegen fehlender Skills einer ansonsten geeigneten Person Schiffbruch erleidet, sollte geprüft werden, den PO zu unterstützen, z.B. durch Coaching oder einen entsprechenden Sparringspartner (so wie ja die SW-Entwicklung auch sehr gute Erfahrung mit dem Pair Programming gemacht hat).
Einige Projekte haben auch gute Erfahrungen mit PO-Teams/Paaren gemacht, indem z.B. jeweils ein Fachmann und ein IT-Mann an einem Produkt gemeinsam als PO arbeiten. In diesen Fällen muss aber unbedingt dafür gesorgt werden, dass das Paar nach außen immer eine konsistente Meinung vertritt (wie Eltern ggü. ihren Kindern).
Auf jeden Fall sollte man die mangelnde Kompetenz (oder auch den Ausfall) des PO als ein zentrales Risiko im Risikomanagement des Projekts behandeln (ich gehe davon aus, dass jeder Leser die Bedeutung von Risikomanagement für Projekte kennt).
Fazit
Wer für die Entwicklung von Softwareprodukten agile Prozesse wie Scrum praktiziert, darf nicht automatisch von so großem Erfolg seiner Software wie Google & Co. ausgehen, zumal wenn Software nicht seine eigentliche Unternehmensmission ist.
Zwar gilt – nicht zuletzt dank den digitalen Vorreitern: Agile Softwareentwicklung, also das iterative Fortschreiben einer Software bei gleichbleibend hoher Qualität, ist heute kein Hexenwerk mehr. Methoden und Tools sind ausreichend etabliert bzw. können Teammitgliedern schnell vermittelt werden. Gerne unterstützen wir auch hierbei, z.B. bei der Einführung von Behavior Driven Design, das wir für eine perfekte Ergänzung agiler Methodik halten (es kann übrigens auch massiv zur Entlastung des POs führen).
Ein sinnvolles und marktwirksames SW-Produkt zu konzipieren und iterativ zu entwickeln ist ungleich schwerer, wenn es eine nicht-triviale konzeptionelle Komplexität besitzt. Die Verantwortung hierfür liegt in Scrum beim Product Owner. Dies ist in der Regel eine einzelne Person, die einen großen Umfang an Skills und Fertigkeiten braucht. Eine Fehlbesetzung dieser Rolle stellt ein sehr hohes Risiko für das Projekt dar.
Sollten Sie im Umfeld Ihrer Projekte diesbezüglich Bedenken oder Probleme haben, sprechen Sie uns bitte an. Wir unterstützen Sie gerne mit unserer Expertise, z.B. in Form von Trainings, Workshops, Coaching oder Entlastung Ihres Product Owners.