Buchrezension: Agiles Produktmanagement von Roman Pichler

Inhalte und Learnings

Zum einen gibt das Buch einen sehr guten Überblick über die Rolle des Product Owners und mögliche Organisationsstrukturen. Insbesondere empfinde ich den Punkt, dass ein Product Owner die Entscheidungsgewalt haben sollte, als sehr wichtig. Es erschwert die Entwicklungsprozesse, wenn immer weitere Entscheider mit reingeholt werden müssen. Genauso habe ich in den letzten Jahren häufiger die Trennung zwischen PO (zuständig für Vision, Roadmap) und PM (Zuständig für Stories und Organisation des Teams) erlebt. Hier kann ich definitiv Pichlers Meinung unterschreiben, dass das meist keinen Sinn macht, da so zu viele Informationen verloren gehen und Abstimmungen nötig sind. Viel sinnvoller ist es, dass das Team (Entwickler, UX,…) Aufgaben übernimmt und den PO entlastet.

Auch die Darstellungen im Bereich Prozesse beinhalten sehr wichtige Artefakte. Sei es die Notwendigkeit der Definition einer einfachen und verständlichen Vision mit dem gesamten Team, die Darstellung des Vorgehens in Roadmaps oder die Visualisierung des Backlogs. In Letzterem sollten nur wenige ausspezifizierte Stories stehen und sonst die Übersicht über grobe Epen, Userflows etc. erfolgen.

Auch viele Methoden, die jeder PO kennen sollte, sind schließlich Bestandteil des Buches. Genannt wird hier beispielsweise die 3C Methode (Card, Conversation, Confirmation), die besagt, dass Userstories einfach formuliert und mindestens einmal mit dem Team abgestimmt werden sollten und testbar sind. Eine Darstellung der Unterschiede zwischen Themes, Epics und User Stories wird beschrieben sowie die Berechnung der Velocity und vieles mehr.

Umstrittene Punkte

Nichtsdestotrotz sehe ich ein paar Punkte differenzierter - wie bereits geschrieben, sind hier meine Erfahrungen einfach anders.

Visualisierung der Artefakte über Aushänge

Pichler beschreibt immer wieder, dass es wichtig ist darzustellen was das Team macht, um andere Teams und Stakeholder abzuholen. Das kann ich zu 100% bestätigen. Seine Lösung ist es Artefakte wie Boards in die Teamzimmer zu hängen. Und hier muss ich widersprechen, da das aus meiner Sicht nicht aussreicht. Nur wenige Stakeholder kommen vorbei, um sich die Roadmap oder das aktuelle Backlog anzusehen und wenn sie es tun, dann werden sie die Inhalte teilweise nicht verstehen. Das hat zur Folge, dass sie nicht über Themen informiert sind und es zu Diskussionen, Unklarheiten und ggf. sogar Umpriorisierungen kommt.

Mein Learning ist, dass es immer wichtig ist proaktiv zu kommunizieren. Klar passiert dies teilweise durch Review Termine. Ich habe jedoch sehr gute Erfahrungen damit gemacht, unabhängig von den Scrum Reviews Zusatztermine einzuplanen, bei denen sowohl die letzten Themen als auch die kommenden detailliert besprochen werden und es danach auch eine kurze Zusammenfassung gibt. Dieser Zusatzaufwand  hat für mich immer sicher gestellt, dass alle relevanten Stakeholder informiert waren und meine Planung mitgegangen sind. Wie das aussieht? Das kann ein Meeting sein, oder eine “Messe” bei der die Teams die aktuellen Themen an verschiedenen Ständen präsentieren. Bitte tut mir nur den Gefallen, dass ihr nicht davon ausgeht: Ich habe das Board ausgehängt, dadurch weiß jeder was passiert.

Productvision Board

Pichler stellt das von ihm entwickelte Product Vision Board vor, um Visionen zu entwickeln und darzustellen. Damit habe ich an sich schon gute Erfahrungen gemacht. Es funktioniert sowohl für die Vision des Gesamtprodukts, als auch für die daraus resultierenden Visionen pro Bereich (wie auch immer diese geschnitten sind). Was ich hier allerdings suboptimal finde ist die Darstellung des Punktes Wirtschaftlichkeit. Dazu verwendet Pichler verschiedene Felder aus dem Business Model Canvas (insgesamt 7 der 9 Felder des Canvas), was die Übersicht doch erschwert und die Inhalte verkompliziert. Aus meiner Sicht ist es auch ein Thema, was sich nach und nach entwickelt und durch Zusatzinhalte angereichert wird. Insofern wäre meine Empfehlung, auch den Punkt Wirtschaftlichkeit durch reduzierte Aussagen zu vereinfachen.

Henry Ford und das Customer Development

Wie so viele zitiert auch Pichler Henry Ford: “Wenn ich die Nutzer gefragt hätte, dann hätten sie sich ein schnelleres Pferd gewünscht.” Ähnlich auch die Aussage von Steve Jobs, dass die Nutzer ihm nie ein iPhone beschreiben hätten können. Dadurch argumentiert Pichler, dass es aus seiner Sicht nicht möglich ist den Nutzer in der ersten Phase (Visionsentwicklung) einzubeziehen, sondern erst wenn die Lösung detailliert steht bis hin zum ersten Prototypen. Hier muss ich vehement widersprechen. Klar kann kein Nutzer beschreiben wie die Lösung aussieht. Gerade im innovativen Bereich kann sich ein Nutzer mögliche Lösungen nicht vorstellen, ABER: ein Nutzer hat Probleme und Bedürfnisse, aus denen sich Lösungen ableiten lassen, was definitiv der Job des POs ist. Also ist das richtige Vorgehen Nutzer zu befragen, ihre Probleme zu verstehen und daraus dann die Lösung abzuleiten. Die Nutzer, die Henry Ford befragt hätte, hätten geantwortet sie wollen schneller von A nach B kommen. Ob die Lösung ein schnelles Pferd, ein Auto oder gar das Beamen sein könnte, obliegt dem PO. Er sollte Lösungen finden, sie gemäß Aufwand, Nutzen und Problemlösung und weiteren Faktoren evaluieren und bauen. Nicht umsonst ist das Prinzip von Lean Startup und Customer Development den Kunden von Anfang an in den Dialog mit einzubeziehen. Hier ist meine Empfehlung: Redet kontinuierlich mit aktuellen und potenziellen Zielgruppen. Schließt euch nicht ein, sondern geht raus.

Fazit

Zusammenfassend würde ich nach wie vor das Buch lesen, da es viele interessante Aspekte aufwirft, aber nicht alles als gesetzt empfinden, sondern noch mal für mich interpretieren. Was meint ihr?