Die meisten Leute dich ich in der IT kenne haben bereits Erfahrungen mit Scrum gemacht – oft wird Scrum in den Firmen bereits seit Jahren eingesetzt.
Man möchte also annehmen, dass der gesamte agile Reifegrad hier sehr hoch ist, und der Prozess vollständig agil abläuft. Doch bei der Implementierung von Scrum wird oft ein sehr technischer Fokus angelegt, bei dem es oft nur darum geht die Events und Routinen von Scrum durchzuführen und die Entwicklungsteams zu „agilisieren“. Dabei wird jedoch vergessen, dass Scrum nur dann gut funktioniert, wenn das Produktmanagement auch agil arbeitet und sich der Arbeitsweise anpasst.
Und obwohl der Scrum Guide viel Gutes zu Product Backlog, Planning und der Rolle als Product Owner zu sagen hat, ist es doch viel zu wenig, um damit in der Praxis zu überleben.
Ein paar Beispiele, was ein Product Owner laut dem Scrum Guide tun muss:
- „Developing […] the Product Goal“
- „Ordering Product Backlog items“
- „The Product Owner proposes how the product could increase its value”
Product Owner, die ich geocached habe, haben mich dann gefragt: „Und wie mache ich das?“ Wie erstelle ich denn am besten ein Produkt-Ziel, bzw. eine Produkt Vision? Nach welchen Regeln soll ich denn im Backlog priorisieren? Und wie spielt hier nun der „Wert“ (engl. „Value“) mit hinein?
Und genau hier liegt der Knackpunkt: Scrum fordert diese Dinge ein, fokussiert sich jedoch auf das eigentliche Entwicklungsframework – Eine Entscheidung, die natürlich aus der Sicht von Scrum.org völlig richtig ist, denn man kann ja nicht alle Funktionen und Disziplinen abdecken.
Und genau diese Lücke wollte ich mit meinem Vortrag auf der Modern RE schließen: Ziel sollte es sein Produktverantwortlichen Werkzeuge und Vorgehen an die Hand zu geben, mit denen sie strukturiert diese täglichen Probleme lösen können. Dazu habe ich ein zusammenhängendes Set an Best-Practices zusammengestellt.
Eigentlich war das Ganze nur als Vortrag geplant – je länger ich mich jedoch damit beschäftigte all die Erfahrungen zusammenzufassen, desto mehr habe ich festgestellt, dass die Zusammenhänge komplexer sind, als sie zunächst erscheinen. Denn als Coach analysiert und unterstützt man meistens nur dort, wo die größten Lücken bestehen, denn es brennt ja oft an vielen Stellen gleichzeitig. Dabei hat man den „Idealprozess“ bereits im Kopf – vermittelt aber immer nur den gerade benötigten Teil.
Im Laufe des letzten halben Jahres habe ich mich also mal hingesetzt und diesen „Idealprozess“ aufgeschrieben und unter https://agileproductmanagement.org/ für alle frei zugänglich veröffentlicht.
Das Framework ist visuell aufgebaut, sodass man es möglichst schnell verstehen kann - Denn wir haben alle wenig Zeit hunderte von Seiten zu lesen
Ihr könnt also entweder die einzelnen Schritte durchgehen, oder euch die Zusammenfassung als handlichen Guide herunterladen
Zusätzlich gibt es noch jede Menge Beispiele und Templates, die ihr nutzen könnt für eure agile Produktentwicklung
Ich würde mich freuen, wenn es dem ein oder anderen hilft besser mit der Herausforderungen agiler Produktentwicklung umzugehen und freue mich auf Feedback dazu.