Doch Produktplanung ist eigentlich eine sehr agile Vorgehensweise. Vor allem dann, wenn wir mit Zielen planen. Klare Ziele, Mehrwert und Nutzen, motivieren ein Team loszulegen. Wie wir das das Ziel erreichen, ist dabei aber völlig offen und läuft agil ab.

Im Zuge einer agilen und zielorientierten Produktplanung agiert ein Produktteam auf drei Ebenen. Vision, Roadmap und Backlog.

1. Die Vision

Die Vision bringt alle Gedanken und Ideen für die Neu- und Weiterentwicklung eines Produkts zusammen. Sie konkretisiert den Auslöser für das Vorhaben und motiviert alle Beteiligten loszulegen. Dabei hilft sie, indem wir Zielgruppe und deren relevanten Probleme/Bedürfnisse beleuchten. Sie erfordert einen groben Umriss des neuen Produkts und stellt die Businessziele heraus. Kurz gesagt ist die Vision, das langfristige Ziel. Richtung und Erfolg der Produktentwicklung werden an ihr gemessen. Der Auftrag des Teams wird mit Stakeholdern geklärt.

Hört sich leicht an, oder? Ist es aber nicht, denn schon die Vision erfordert für viele ein Umdenken von einem Bauchgefühl hin zu einer Konkretisierung. Aber genau das ist das Wichtige, um sich nicht schon früh in einem diffusen Raum von unklaren Zielen und Vorstellungen zu verlieren.

Zwei Frameworks mit entsprechenden Steckbriefen zur Visionserstellung kann ich hierfür empfehlen:

• Product Vision Board von Pichler http://www.romanpichler.com/tools/vision-board/
• Auftragsklärung von Xing https://auftragsklaerung.com/

Beide durchleuchten die relevanten Elemente einer Vision und helfen hier strukturiert vorzugehen. Die „Auftragsklärung“ beleuchtet die äußeren Rahmenbedingungen stärker.

Beide Ansätze helfen, sich auf das Wesentliche zu fokussieren:

• Für welche Zielgruppe lösen wir Probleme bzw. welches Bedürfnis welcher Zielgruppe adressieren wir?
• Welche Ziele setzt man sich für das Vorhaben?
• Was soll das Produkt umfassen, was liefert es?

Man bewegt sich hier schnell in einem schwammigen Raum. Daher hilft es, solange alles immer wieder zu hinterfragen, bis es konkret wird. Mein Tipp: Die gute alte 5-Whys Methode anwenden. Nur so werden das wirkliche Problem, das echte Bedürfnis und das konkrete Ziel transparent. Schlechte Beispiele wie „Wir wollen die Daten verbessern“ und „Unsere Kunden sollen eine Software nutzen, die den neuesten UX-Anforderungen entspricht“ helfen niemanden.

Die Vision ist die Grundlage für die Roadmap und das Backlog.

2. Die Roadmap

In dieses Thema ist in den letzten Jahren viel Bewegung gekommen. Viele Blogs schreiben über die Product Roadmap für agile Produktteams. Trotzdem: Der Regelfall für agile Teams ist aber immer noch ein klassischer Projektplan („dann starten wir und dann sind wir mit genau diesen technischen Features fertig“) der für Auftraggeber erstellt wird. Doch genau diese Mentalität – ob vorgegeben oder frei gewählt – hilft einem agilen Team nicht.

Gibt man über eine Roadmap jedoch klare fachliche Ziele vor („Dieser Mehrwert für Kundengruppe Y soll bis Datum X erreicht werden“, „Dazu wollen wir bis Datum X befähigt sein“), kann das Team agil agieren, um das Ziel zu erreichen. Zudem beinhaltet die Roadmap pro Ziel Metriken, um die Erreichung zu messen. All das gibt ein Projektplan nicht her.

Zur Etablierung einer Product Roadmap empfehle ich ein Framework: Die GO-Roadmap von Pichler http://www.romanpichler.com/tools/product-roadmap/

Die GO Roadmap fokussiert sich auf bis zu vier Releases, die aus fünf beschreibenden Elementen bestehen:

• Das Release-Datum, üblicherweise der letzte Tag im Quartal oder Monat
• Der Release-Name
• Das Release-Ziel das erreicht werden soll
• Die Features die zur Erreichung des Release-Ziels notwendig sind
• Die Metriken um die Erreichung des Ziels zu messen

Roadmap-Ziel

Das Ziel beschreibt die Motivation hinter dem Release. Hier soll der Mehrwert klarwerden. Ein eher schwammiges Ziel („Funktionalität … wird released, optional auch Funktionalität …“) ist schnell aufgestellt und lässt zur Erfolgsmessung viel Spielraum zu, hilft aber auch niemanden so wirklich. Ein scharfes Ziel („Die neue Funktion … ermöglicht unseren Kunden … und erleichtert so ….“) ist die Basis für fokussierte und zielorientierte Arbeit. Natürlich ist ein scharfes Ziel von Anfang an verbindlicher.

Roadmap-Features

Die aufgeführten Features zeigen die Funktionalität auf, die zur Erreichung des Ziels notwendig ist. Auch hier helfen eine fachliche Beschreibung der Funktionalität und keine technische Komponente.

Roadmap-Metriken

Die Aufstellung von Metriken ist nicht einfach. Sie messen, ob wir das Ziel erreicht haben (quantitativ und/oder qualitativ). Schnell neigt man zur Aufstellung von sog. Vanilla Metrics, also solchen Metriken die keinen wirklichen Mehrwert oder Erfolg messen. Ein Beispiel dafür sind Metriken á la „Die Anzahl der Visits erhöht sich um 45%“. Dies alleine macht keine Aussage über den Mehrwert eines Ziels – vermutlich ist jenes schon schlecht formuliert. Der Artikel Data-Driven Product Roadmaps – Choosing the Right Metrics erklärt die Arbeit mit Metriken sehr eingängig. Auch hier gilt wieder das Prinzip des Fragens nach Was und Warum.

Roadmap-Methodik

Als eine mögliche Methode für die Erstellung einer Roadmap wird auch das User Story Mapping aufgeführt. Meiner Erfahrung nach bewegt sich ein Team damit zu früh auf der Story-Ebene und diese wandern dann zu früh in das Backlog. Erfahrungsgemäß lohnt sich die frühe Erstellung einer Vielzahl an Stories – lange vor ihrer Umsetzung – nicht. Der Weg der Umsetzung wird zu schnell festgelegt und lässt eher wenig Platz für neue Ideen. Und wer kennt es nicht: Alte User Stories werden fast immer kurz vor der Umsetzung wieder überarbeitet.

Je nach Reife des Produkts und Volatilität des Umfelds (Organisation, Markt) wird die Roadmap monatlich oder quartalsweise angepasst. Sprich, bei einem noch jungen Produkt und/oder einem sich ständig änderndem Umfeld aktualisiert man monatlich. Erreicht das Produkt eine gewisse Reife und/oder beruhigt sich das Umfeld, kann man quartalsweise aktualisieren. Bei der Aktualisierung werden Team und relevante Stakeholder eingebunden. Dabei analysieren wir die Zielerreichung vom letzten Release und planen die nächsten Releases.

3. Das Backlog

Inhalt und Priorisierung des Backlogs werde nun maßgeblich an Vision und Roadmap ausgerichtet. Für die Mehrheit der User Stories muss klar sein, wie sie auf Roadmap-Ziele einzahlen. Die Priorisierung richtet sich ebenfalls an dem Ziel aus. Ein guter Einstieg zu Priorisierungstechniken findet sich hier.

Features aus der Roadmap generieren Epics und/oder Themes für das Backlog. Die Walking-Skeleton Methode ist gut geeignet, um schnell einen zielgerichteten Prototyp anhand von Ziel und Features zu bauen. So lassen sich frühzeitig Komplexitäten aufdecken und die Richtigkeit des Ziels überprüfen.

Und alles zusammen…

Die drei Ebenen der Produktplanung Vision, Roadmap und Backlog ermöglichen einem Team über einen längeren Zeitraum zu planen und dabei agil zu bleiben. Aber: In Zielen zu denken erfordert Umdenken. Den Problemraum zu erforschen erfordert Umdenken. Erfolg ehrlich zu messen erfordert Umdenken. Nicht resignieren, wenn beim ersten Versuch noch nicht alles klappt. Ausprobieren, Team und Stakeholder einbinden, Probleme verstehen, Probleme lösen und wieder probieren. Und nicht vergessen: Eine One-Man Show des Product Owner ist nicht sinnvoll. Alle – Team, ScrumMaster, Stakeholder – müssen für eine Produktplanung am selben Strang ziehen.

The post Zielorientierte agile Produktplanung appeared first on Reza Nazarian.

Ich stelle hier ein paar Tipps vor, die hilfreich zur Etablierung eines guten Stakeholder-Managements waren. Wie zu Beginn von neuen großen Aufgaben ist auch hier zunächst Überblick und Priorisierung wichtig.

1. Mit einer Stakeholder-Matrix priorisieren

Wer sind eigentlich Stakeholder? Jeder der ein Interesse am Produkterfolg hat, beispielsweise…

• Fachabteilungen
• Abhängige Produktteams
• Vertrieb
• Marketing
• Produktmanager
• Führungskräfte aus dem Umfeld des Teams
• Geschäftsführung

Da kommen sehr schnell sehr viele Personen zusammen. Das erschwert die Einbindung ungemein und blockiert das gemeinsame Vorankommen. Bevor willkürlich nur die Lieblings-Stakeholder ausgewählt werden, empfehle ich zunächst den Aufbau einer Stakeholder-Matrix. Einfach und bewährt ist das Power-Interest Grid, das Colin Eden und Fran Ackermann in ihrem Buch „Making Strategy“ veröffentlicht haben.

Stakeholder werden über vier Quadranten verteilt, abhängig von dem Interesse am Erfolg des Produkts und dem Einfluss auf Organisation und Produktentwicklung. Diese Einteilung hilft, um die Stakeholder zu identifizieren, die die Produktentwicklung vorantreiben können und wollen. Folgende Einteilung ergibt sich:

• Player –  z.B. verantwortliche Produktmanager, Auftraggeber und Manager aus Fachabteilungen mit denen das Team eng zusammenarbeitet.
• Subjects – z.B. interessierte Produktmanager und abhängige Produktteams, die die Marschrichtung des Teams nicht spürbar beeinflussen, deren Feedback oder Beratung jedoch wichtig ist.
• Context Setters – z.B. mittleres und höheres Management. Nehmen nicht an der Produktentwicklung teil, schaffen jedoch organisatorische Rahmenbedingungen.
• Crowd –  Alle anderen, die über das Produkt informiert werden, jedoch keinen Einfluss auf Produktentwicklung haben.

2. Mit den Playern Zusammenarbeiten, Subjects einbinden

Für die Ausarbeitung von Vision, Strategie, Roadmap und Backlog übernimmt das Produktteam die Ownership, Player werden aber aktiv eingebunden – nur so wird Akzeptanz hergestellt. Workshops wie regelmäßige Roadmap-Updates oder die Ausarbeitung der Produktvision werden also mit ihnen vorbereitet und durchgeführt.

Was die Team-Meetings angeht, werden Stakeholder nur zum Sprint-Review eingeladen. Hier sehen die das Produkt-Inkrement und geben Feedback, ob alles in die richtige Richtung geht. Stand-Ups, Plannings, Refinements und Retrospektiven fokussieren sich auf das Team. Die Anwesenheit von Stakeholdern dort ist kontraproduktiv.

3. Warum? … Warum? … Nein!

Auch wenn es anstrengend werden kann: Um aus Anforderungen Features werden zu lassen, müssen alle Beteiligte Inhalt und Mehrwert verstehen. Das ist die Grundlage, damit Entwickler nicht nur Arbeit nach Vorschrift machen. Der Product Owner hinterfragt jeden relevanten Input der Stakeholder so lange, bis Inhalt und Mehrwert verständlich sind. Die kontinuierliche Hinterfragung und das Liefern der Antworten ist meistens anstrengend, aber nur trennen sich unausgegorene Themen von wichtigen.

Jeder Product Owner darf „Nein“ zu seinen Stakeholdern sagen. Wenn Anforderungen und Ideen schwammig sind oder einfach nicht passen, lehnt er sie besser ab. Wenn spontane Anforderungen gemeinsame Planungen und Strategie torpedieren, ist ein „Nein“ angebracht.

4. Empathie angewöhnen

Ist die Beziehung zwischen Produktteam und Stakeholder distanziert, so lassen sich auch entsprechende Verhaltensmuster beobachten.

• Produktteam: „Wir wissen am besten, was richtig und falsch für unser Produkt ist“
• Produktteam: „Stakeholder nerven nur“
• Stakeholder: „Das Team arbeitet echt langsam“
• Stakeholder: „Die wollen mitreden, obwohl die gar nicht wissen, was wichtig ist“

Hier sind erste Annäherungsschritte wichtig und beide Seiten gewöhnen sich am besten eine Portion Empathie an. Dem Produktteam sollte klar werden, dass Stakeholder einem Produktteam viel Vertrauen entgegen bringen. Sie verlassen sich auf teure Spezialisten, die richtigen Produkte zu bauen. Aber auch das Produktteam erwartet, dass Stakeholder ihre Arbeitsweise und Bedürfnisse verstehen.

5. Zur gemeinsamen Planung stehen

Nach gemeinsamer Ausarbeitung von Vision, Zielen, Roadmap etc. sollten diese auch als bindend angesehen werden. Die gemeinsame Planung ist die Grundlage der Zusammenarbeit und der Produktentwicklung. Auch hier hilft ein klares „Nein“ vom Product Owner. Das gilt auch für die Stakeholder. Inkonsequenz und es allen recht machen zu müssen, ist Zeitverschwendung.

The post 5 Tipps für gutes Stakeholder-Management appeared first on Reza Nazarian.