posts by: rezanazarian

Was muss ein Product Owner können?

Agile     no comments    
E„Ein neuer Product Owner wird gesucht. Wie sieht die Stellenausschreibung aus? Beim Lesen von Artikeln über modernes Produktmanagement merken wir, dass unser Produktmanagement hoffnungslos veraltet ist. Wir praktizieren kein Design Thinking, betreiben keine Innovation und der MVP ist schon wieder tot bevor wir ihn verstanden haben. Eigentlich dürfte es uns gar nicht mehr geben, so altbacken sind wir.“ Kommt das irgendwie bekannt vor?

Product Owner = Superman?

Das Lesen von Artikeln auf medium und die Teilnahme an Konferenzen wie MTP formen das Bild des Product Owners des allwissenden Supermans. Er muss einen riesigen Wissensschatz mitbringen, um das Wunderwerk zu vollbringen:

  • Stories schreiben
  • Backlog priorisieren
  • Visionen erschaffen
  • Roadmaps bauen
  • Marktforschung betreiben
  • Stakeholder verstehen und organisieren
  • Kreativ-Workshops durchführen
  • Innovation vorantreiben
  • Produkte vertreiben
  • User Experience ermöglichen
  • Business Modelle ausdenken
  • Finanzvorhersagen treffen

Dass dies relevante Aufgaben eines POs sind, ist richtig. Dass ein PO sich aber perfekt (inkl. vieler Methoden und Tools) und aus dem Stand mit allem auskennen muss, nicht. Ich will mich nun einmal auf die Kernfähigkeiten eines POs zurückbesinnen.

Was sind die Kernfähigkeiten des Product Owners?

Trennen wir uns mal von jeglicher Methodik, Vorgehensweise und von Tools. Was bleibt dann eigentlich noch übrig, mit dem sich ein PO richtig gut auskennen muss?

  • Das Wichtige vom Unwichtigen unterscheiden
  • Die wirklichen Probleme und Bedürfnisse von Kunden erkennen und adressieren
  • Komplexitäten durchdringen
  • Empathisch gegenüber Team und Stakeholdern agieren
  • Von einer klaren Linie überzeugt sein, Nein sagen können

Diese Fähigkeiten (die erlernbar sind) sind das Fundament eines jeden Product Owners. Er läuft sonst Gefahr, sich immer mehr und mehr zu verlaufen, bevor sein Fundament steht. Überspitzt dargestellt: Design-Thinking, MVP, OKR und Lean Startup helfen auf der einen Seite nicht, wenn sich der PO mit unwichtigen Features beschäftigt, am Kunden vorbei plant, das Produkt nicht versteht, sich von Team bzw. Stakeholdern gelöst hat und nur situativ reagiert. Die genannten Methoden erfordern aus meiner Sicht erst das genannte Fundament. Hier ist der PO kein besserer PO, wenn er besonders viel davon kennt, sondern wenn er verstanden hat, wofür er sie einsetzt, und wie sie ihn schneller und besser machen.

Muss ein Product Owner technische Kenntnisse haben?

Nein, aber sie helfen eigentlich immer! Treffen sich Team und PO auf der Architektur-Ebene, finden beide Seiten einen einfacheren Zugang zueinander. War der PO früher selber Entwickler, versteht er es, dass die Lösung zunächst einfacher Probleme mehrere Tage dauern können. Es fällt beiden Seiten leichter, über technische Schuld, Refactoring und Tech-Stories zu sprechen.

Kennt oder beschäftigt sich der PO nur mit der fachlichen Seite, sehe ich ein Risiko: Die Isolation vom Team / der Elfenbeinturm (ein übliches PO-Antipattern). Das muss nicht passieren, wenn beide Seiten über Empathie verfügen und die jeweils andere Seite respektieren. Doch ein PO isolierter PO kann in Discoveries, unzähligen Canvasses usw. abdriften. Er verliert dann immer die Bindung ans Team, weil ihn kaum noch jemand versteht. Einen schönen Artikel dazu gibt es hier.

Wieder auf den Boden der Tatsachen zurückfinden

Die Suche nach dem PO-Superman ist nicht sinnvoll. Man wird ihn nur schwer finden. Diese Notwendigkeit ist stark aus dem Rockstar-Image des Product Owners geboren. Methoden und Werkzeuge sind nur Mittel zum Zweck. Sie einzusetzen, um gefühlt dran zu bleiben, hilft nicht. Wenn man aber das konkrete Problem/die Komplexität verstanden hat und sie versucht zu durchdringen, ist es richtig, die passende Methode zur Lösung zu suchen.

Dann teilen wir die Rolle einfach?

Aber ich möchte wieder zur langen Liste von Aufgaben zurückkehren. Das breite Spektrum lässt sich mit den genannten Kernfähigkeiten inhatlich gut adressieren, es bleibt aber viel Arbeit. Ist das Produktteam groß, die Stakeholder-Landschaft komplex oder die Anzahl der Produkte groß, so muss sich der PO mit der Skalierung seiner eigenen Rolle beschäftigen. Dazu hat Roman Pichler drei sinnvolle Optionen beschrieben. Kurz gesagt managed der PO ein PO-Team (z.B. mit einem Business Analysten und einem UX-Experten) oder das Produkt wird zerteilt. Meiner Meinung nach sind das die richtigen Optionen. Beim PO-Team ist liegt die Verantwortung immer noch beim PO und nicht verteilt. Die Zerteilung von Produkten ist nicht einfach, schafft aber auch klare Strukturen. Ein sehr ungünstiges Modell ist die Zerteilung der PO-Rolle in ein Zwei- („PO-Technisch“ und „PO-Fachlich“), Drei- („PO-Technisch“, „PO-Fachlich“, „PO-Management“) oder gar Viergestirn („PO-Technisch“, „PO-Fachlich“, „PO-Organisatorisch“, „PO-Feelgood-Management“). Zum Einen entsteht diese Zerteilung meist am Reißbrett und hat ihren Ursprung in alten Abteilungsstrukturen (Produktmanagement, Software-Development, Projektleitung). Zum Anderen fördert eine solche Konstellation komplexe und unklare Wege in Kommunikation, Entscheidung und Verantwortung.

Zielorientierte agile Produktplanung

Agile , Planung     no comments    
AAgile Produktteams fokussieren sich gerne auf ihr Backlog. Jegliche Produktplanung darüber hinaus fällt schnell in die Kategorie „nicht agil“. Verständlich, schließlich erinnert „Planung“ an „Projektplan“. Tatsächlich kommt ein agiles Team mit einem nicht agilen Management in den Konflikt. Die eine Seite plant Sprint für Sprint, die andere will Budgets und Produktreleases planen – mindestens für ein ganzes Jahr. Das beißt sich.

Doch Produktplanung ist eigentlich eine sehr agile Vorgehensweise. Vor allem dann, wenn mit Zielen geplant wird. Klare Ziele die eindeutig darstellen, dass Mehrwert und Nutzen erreicht wird, motivieren ein Team loszulegen. Wie das Ziel erreicht wird, 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 Zielgruppe und deren relevanten Probleme/Bedürfnisse beleuchtet werden. 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:

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 soll welches Problem gelöst werden bzw. welches Bedürfnis welcher Zielgruppe soll adressiert werden?
  • 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/


go 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

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.

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.

Die Aufstellung von Metriken ist nicht einfach. Sie messen, ob das Ziel erreicht wurde (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.

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.

Zurück. 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 wird die Zielerreichung vom letzten Release analysiert und die nächsten Releases geplant.

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

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.

Schätzung – Die Spitze des Eisbergs

Agile     no comments    
DDie Schätzung eines agilen Teams können für dieses ein leidiges Thema sein. Beim Wechsel von Feinkonzeptionen und reinen Aufwandsschätzungen hin zu agiler Softwareentwicklung und Story Points beobachte ich diese Verhaltensweisen:

  • Stakeholder außerhalb des Teams denken weiterhin in Aufwandsschätzungen, Projektbudgets, Gantt-Charts und Ressourcen („1 Entwickler braucht 4 Tage, 2 brauchen 2“). Story Points und Team-Velocity werden mit hoher Komplexität auf die alten Artefakte umgerechnet.
  • Das Entwicklungsteam entscheidet sich für die Verwendung von idealen Manntagen, hat aber keinen sinnvollen Umgang mit externen Abhängigkeiten und Risiken gefunden. Ein Teil des Teams schätzt risikoreiche Stories höher als der andere Teil der nur in ideale Manntage schätzt.
  • Der Fokus des Schätzens liegt auf der Zahl an der Story. Ob nach Abarbeitung der Story die Schätzung gut oder schlecht war, ist zweitrangig. Das Team lernt nicht daran.
Ist diese Zahl wirklich so wichtig?

Die Idee des Schätzens im agilen Kontext ist, dass das Team an seinen Schätzungen lernt, ein gemeinsames Verständnis zu Anforderungen, Zielen und Machbarkeit aufbaut. Doch ist die geschätzte Zahl an einer Story wirklich so wichtig für das Entwicklungsteam? Ich meine, dass das Schätzen nur Mittel zum Zweck ist. Sobald ein Team gut darin ist, Stories zu durchdringen, zu verstehen und sie anhand von Komplexitäten zu zerteilen oder zusammenzuführen, ist die eigentliche Zahl überflüssig. Denn wenn das Team ein verlässliches Gefühl dafür entwickelt, welche Stories zusammen in einen Sprint passen, hilft die Zahl nicht mehr. In der Praxis hieße das, dass so etwas wie ein Backlog-Refinement weiterhin genutzt wird, um Stories vorzustellen, zu hinterfragen und anders zu strukturieren. Die Schätzrunde fällt aber weg.

Von der Altlast zum Lernen

Der Fokus der agilen Transition eines Teams liegt daher zunächst darauf, dass die Schätzungen eines Teams nur dem Team dienen sollen. Das bedeutet, dass das Team nicht deswegen schätzt, um externe alte Prozesse zu bedienen (die Erreichung dieses Ziels ist in vielen Organisation eine große Aufgabe). Sehr hilfreich ist auch die Einführung der Komplexität für Story Points. In idealen Manntagen geschätzte Stories lassen sich sicherlich gut in alte Strukturen hinein berichten. Übliche Risiken und externe Abhängigkeiten fließen aber gar nicht in die Schätzung mit idealen Manntagen ein, so dass diese nur bedingt hilfreich sind.

Als Nächstes lernt das Team anhand der Schätzung, Sprints optimal auszulasten und ob an der Schätzung etwas verbessert werden muss. Wenn das länger sicher funktioniert kann auf die eigentliche Schätzzahl verzichtet werden.

Hilfreiche Apps für erfolgreiche Workshops

Workshop     no comments    

SSo anschaulich Ergebnisse eines Workshops auf Flipcharts und Pinnwänden auch sind, sie eignen sich nicht zur dauerhaften Aufbewahrung und zur Verteilung über digitale Kanäle. Ich möchte hier einige Apps vorstellen, die sich für mich bei der Aufbereitung von Workshop-Ergebnissen bewährt haben. Zudem stelle ich noch drei Apps vor, die Visualisierung und Prototyping während eines Workshops sinnvoll unterstützen. 

CamScanner Pro

CamScanner erfasst den Inhalt von Whiteboards, Flipcharts und sonstigen Dokumenten. Die Ränder des Dokuments oder des Boards werden zuverlässig erkannt, wenn auch nicht ganz so wie bei Office Lens. Sehr gute Lichtverhältnisse sind erforderlich – eine Nachjustierung per Hand ist aber einfach möglich. Die Aufnahme wird danach – je nach Auswahl – automatisch optimiert oder es wird händisch ein Verfahren gewählt (z.B. nur Aufhellen). Aufnahmen lassen sich im Einzel- oder Batch-Modus vornehmen, um diese dann zu einem Dokument zu arrangieren. Jede Aufnahme bildet dabei eine Seite. Ist man damit fertig, wird das Dokument als PDF oder JPG exportiert und in gängige Speicher- und Notizdienste (Dropbox, Evernote, Google Drive, iCloud, OneNote) geladen. Ebenso kann das Dokument gedruckt oder per Email versendet werden.

Ergebnisse eines Workshops mit CamScanner aufbereitet

Diese App setze ich in den meisten Workshops ein. Zuschneiden und Auswahl von vorgefertigten Verfahren zur Optimierung geht schnell von der Hand. Das Arrangieren von einzelnen Aufnahmen zu einem Dokument und der anschließende Export ist leistungsfähig. Auch wenn mir die automatische Aufbereitung der gesamten Aufnahme bei Office Lens und die Einzel-Optimierung von Haftnotizen bei Post-it Plus besser gefällt, ist CamScanner das leistungsfähigere Gesamtpaket.

  • Hersteller: INTSIG
  • Preis: 1,99 – 4,99$
  • iOS: Link
  • Android: Link

Office Lens

Eine schlanke Alternative zum CamScanner. Diese App von Microsoft erkennt – je nach Vorauswahl – Dokumente (inkl. Flipcharts), Whiteboards, Fotos oder Visitenkarten. Eine einfache automatische Aufbereitung mit Entzerrung und perspektivischer Korrektur des Fotos findet auch statt.

Darüber hinaus gibt es eine Exportfunktion die für eine oder mehrere Aufnahmen Microsoft-Applikationen (OneNote, OneDrive, Word, PowerPoint und Outlook) bedient, nach PDF konvertiert oder per Email versendet.

Aufnahme mit Office Lens

Ergebnisse eines Workshops mit Office Lens aufbereitet

Alles in allem liefert die App sehr gute Ergebnisse. Erkennung des Hintergrunds und  automatische Aufbereitung klappen in den allermeisten Fällen hervorragend – gute Lichtverhältnisse vorausgesetzt. Zuverlässig sind dabei auch Entzerrung und perspektivische Korrektur. Im Vergleich zu CamScanner fehlt allerdings eine erweiterte Funktionen zum Export. Erkennung des Hintergrunds und automatische Aufbereitung sind etwas leistungsfähiger als beim CamScanner.

  • Hersteller: Microsoft
  • Preis: Gratis
  • iOS: Link
  • Android: Link

Post-it® Plus App

Hier liegt der Fokus auf das digitale Einsammeln von Haftnotizen. Die App erkennt einzelne Notizen auf Hintergründen, isoliert und optimiert sie einzeln. Extrahierte Notizen können verschoben und neu arrangiert werden. Sehr hilfreich, wenn nach einem Workshop mit einem verteilten Team weiter gearbeitet wird. Hierfür gibt man die Ergebnisse einfach Kollegen frei. Die Exportfunktion sieht u.a. PDF, Powerpoint und Dropbox vor.

Erkennung in der App Ergebnisse eines Workshops mit PostIt Plus aufbereitet

Die Extraktion klappt sehr gut, auch die Aufbereitung der einzelnen Notizen. Die Ergebnisse sehen sehr sauber und ansehnlich aus. Erforderlich ist aber – neben guten Lichtverhältnissen – sichtbarer Abstand zwischen den Haftnotizen. Wer gerne mit Haftnotizen arbeitet und die Ergebnisse sauber in digitale Form überführen möchte (für Präsentationen, für die weitere Arbeit mit verteilten Teams) für den ist diese App sehr hilfreich.

  • Hersteller: 3M Company
  • Preis: Gratis
  • iOS: Link

Time Timer

Diese App bildet die beliebte Time Timer in einer digitalen Variante ab. Mit der App lassen sich wie beim physikalischen Pendant Countdowns einstellen, die nach Ablauf einen Alarm abspielen. Der Countdown wird mit dem Finger eingestellt.

Einstellung in TimeTimer

Der minimalistische Countdown ist das Basis-Tool für alle mit Timeslots durchgetaktete Workshops. Gegenüber der physikalischen Variante spart die App viel Platz im Gepäck.

  • Hersteller: Time Timer
  • Preis: 0,99$ – 2,99$
  • iOS: Link
  • Android: Link

POP – Prototyping on Paper

Mit POP lassen sich einzelne Aufnahmen zu einem Prototypen mit GUI und User-Flow arrangieren. Das klappt in Windeseile und so lassen sich Ideen und Lösungsansätze schnell ausprobieren.

Die Aufnahmen werden wie Screens ins Applikationen behandelt. Dazu malt man den Screen auf Papier, nimmt ihn mit dem Smartphone auf und schneidet ihn zu. In den Screens markiert man beliebige Flächen und weist diesen ein Klick- / Tapverhalten zu. So ein Verhalten ist die Transition von einem Screen auf einen anderen. Ebenso lassen sich Gesten der Transition auf einen weiteren Screen zuordnen.

Screenshot aus POP

Die App ist unverzichtbar, wenn in kurzer Zeit Prototypen von Apps gebaut werden. Perfekt für Ideation-Workshops geeignet, mindestens ein Smartphone pro Arbeitsgruppe vorausgesetzt.

Der Preis der App richtet sich nach der Anzahl der Projekte die mit POP bearbeitet werden. Die Gratis-Variante erlaubt immerhin 2.

  • Hersteller: Microsoft
  • Preis: 0 – 25$
  • iOS: Link
  • Android: Link

 

5 Tipps für gutes Stakeholder-Management

Stakeholder     2 comments    
AAnforderungen, Ideen, Ziele, Strategie, Vision und Feedback von Stakeholdern sind wichtige Einflüsse für ein erfolgreiches Produkt-Team. Denn wenn Stakeholder und Produktteam Hand in Hand an einem Produkt arbeiten, stärkt das Akzeptanz und Interesse in der Organisation. Einem Team, das einer komplexen Stakeholder-Landschaft gegenübersteht, liegen Einigeln und Alleingänge allerdings nahe. Mittel- und langfristig bedeutet das aber kräftezehrende Konflikte, da Interesse und Bedürfnis nach Einfluss auf das Produkt von Stakeholdern nicht abreißt. Das mag niemand.

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.
Power-Interest Matrix für die Einordnung von Stakeholdern

Power-Interest Matrix

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.