Dieses Jahr habe ich zusammen mit meinem Kollegen Tschipper an einer PO-Zertifizierung bei Scrum-Ikone Mike Cohn teilgenommen. Es ist erfrischend zu sehen das Mike 2 Jahre später seine exzellente Schulung noch weiter verbessert hat. Sein kritisches Input und seine über 30-jährige Erfahrung mit Softwareprojekten sind die Teilnahmegebühren alleine wert. Ich habe mal einige Highlights zusammengefasst, die mein Handeln in den nächsten Monaten noch deutlicher prägen werden.
An den Anfang seiner Präsentation setzt Mike mitnichten das Scrum Framework, Prozesse und Tools sondern etwas, das er mit “Project Chartering” beschreibt und das er als den wichtigsten Indikator und Schritt für den Projekterfolg bezeichnet. Die ureigene Aufgabe des Product Owners ist es, das Produkt und seinen Zweck für den Enduser durchdrungen zu haben, und als klares Ziel (clear, elevating goal) in wenigen Worten beschreiben zu können. Projekte die mit ebendiesem Ziel ein Kickoff und regelmässige Refresher haben sind seiner Erfahrung nach ungleich erfolgreicher als vergleichbare Projekte ohne Chartering. Für viele Unternehmen bedeutet dies, das sie das Geschäft ihrer Kunden tiefer als bisher durchdringen müssen um auch die Motivation ihrer Endkunden bei der Produktentwicklung vor Augen zu haben – und das sie die dort gewonnenen Erkenntnisse besser als bisher mit in die Teams bringen müssen um dort erfolgreicher zu sein.
Häufig erreicht mich die Frage, wie man Anforderungen erfasst die nicht als User Story formuliert werden können, weil so ein User schlicht nicht existiert. Davon vor allem betroffen sind Infrastruktur- und Sicherheitsthemen. Eine Absicherung der Datenbank hat so keinen “User” sondern ist ein sogenanntes Non Functional Requirement. Hier empfiehlt Mike die Formulierung aus dem FDD, oder Feature Driven Development:
Als wichtigste Eigenschaften eines Product Owners die durch Verbesserung den größten Mehrwert erzeugen nennt Mike Verfügbarkeit und Entscheidungsfähigkeit. Beide Faktoren kann ich nach meinen Erfahrungen bestätigen. Eine hohe Verfügbarkeit eines PO für das Team verhindert Wartezeiten bei Rückfragen und/oder Fehlentwicklungen wenn ohne Input entschieden und weitergearbeitet werden muss. Auch direkt beim Entwicklungsteam zu sitzen hilft ungemein, denn auch im Kleinen ist die direkte Rücksprache sehr wertvoll und das Fachwissen des PO kann maßgeblich zum Erfolg der Entwicklung beitragen. Nur wenn ein PO dabei effektives Stakeholdermanagement betreibt und die verschiedenen Anforderungen zu einem klaren Gesamtbild zusammenfügt ist er ausreichend entscheidungsfähig, wenn neue Erkenntnisse die bisherige Planung beeinflussen. Auch hier gilt ganz klar: Mehr Information führt zu weniger Reibungsverlusten in der Umsetzung.
Zuletzt noch ein wichtiger Punkt für Diskussionen zu Story Points: Wie auf dem Scrumtisch Essen vergangenen Monat diskutiert ist entgegen anderslautender Aussagen für Mike vor allem der Zeitaufwand relevant; Komplexität ist davon nur ein Faktor. Er beschreibt in einem Beispiel das eine Distanz zu einem beliebigen Gebäude in 100 Metern Entfernung zurückgelegt werden soll. Diese, und nur diese, versuchen wir mit Story Points abstrakt zu bewerten. Je nachdem wie (bzw. durch wen) diese Entfernung zurückgelegt wird (per pedes, im Auto, mit dem Flugzeug) ergibt sich ein Faktor an Komplexität der letzten Endes die Zeit beeinflusst die zum Erreichen des Ziels benötigt wird. Story Points geben damit neutral den Aufwand an der zu leisten ist – wenn wir von einer relativ konstanten bis leicht steigenden Kompetenz für die Umsetzung ausgehen ergibt sich so eine stabile Menge an Aufwand die pro Sprint erledigt werden kann. Diese sogenannte Velocity wird zu einer wichtigen historischen Größe, mit deren Verlauf es uns möglich wird mit steigender Wahrscheinlichkeit vorhersagen zu können wie viel wir pro Sprint schaffen – auch wenn wichtige Domänenexperten durch Urlaub oder Krankheit nicht ausfallen, können wir unsere Vorhersage entsprechend anpassen, ohne aufgrund anderer Komplexitäten alles noch mal neu schätzen zu müssen.
Alles in allem war es wieder erhellend, auch mit Kollegen nach Feierabend haben wir viele der Eindrücke weiterverarbeitet. Wer sich mit der Product Owner Rolle auseinander setzt macht sicherlich nichts falsch mit einer Zertifzierung durch einen erfahrenen Coach. Damit hat man den Grundstein gelegt um mit einem Team erfolgreich Projekte im agilen Umfeld bestreiten zu können.
Freut mich, dass Dir der Kurs gefallen hat!
Der Artikel liest sich gut.
Viele Grüße vom PO an den PO 😉