Björn Schotte 19. Juli 2022

Mache Stakeholder zu Fans Deines Produkts!

In der Zusammenarbeit mit Stakeholdern gibt es häufig eine ganze Menge an Herausforderungen. © Adobe: master1305 / stock.adobe.com / 257363791 — © Adobe: master1305

In der agilen Softwareentwicklung gilt gemeinhin, dass der wichtigste Stakeholder die Nutzer des Produkts sind. Doch die Realität zeichnet häufig ein anderes Bild: Neben einer Vielzahl an unternehmensinternen Stakeholdern, die aus anderen Bereichen bzw. Abteilungen stammen oder dem Management angehören, gibt es auch externe Stakeholder, wenn zum Beispiel im Rahmen regulatorischer Richtlinien gearbeitet wird. Ich möchte beleuchten, welche Stakeholder-Arten es gibt, was die typischen Herausforderungen im Umgang mit diesen sind und wie Du den Umgang mit den Stakeholdern signifikant verbessern kannst.

Getreu dem Motto: Mache die Stakeholder zu den größten Fans Deines Produkts!

Wer kann Stakeholder sein?

Es gibt unterschiedliche Typen von Stakeholdern und verschiedene Unterscheidungsmechanismen. Und natürlich ist es von Kontext zu Kontext unterschiedlich. Also abhängig von Deinem Produkt, Deiner Organisation und der Umwelt, die an dieser Organisation hängt (z. B. externe Lieferanten und Partner).

Am einfachsten ist es, zwischen internen und externen Stakeholdern zu unterscheiden. Die internen Stakeholder sind das eigene Team, aber auch angrenzende Fachabteilungen oder das Management. Zu den externen Stakeholdern zählen natürlich die Anwender des Produkts, aber auch zum Beispiel Lieferanten und Partner.

Du kannst Dir die Menge Deiner Stakeholder aber auch als "Stakeholder-Zoo" vorstellen. Jeder Stakeholder-Typ repräsentiert ein bestimmtes Tier im Zoo mit entsprechenden Eigenschaften. Da gibt es also das HIPPO, die "Highest Paid Person’s Opinion". Oder aber auch den WOLF, der immer das aktuellste Feuer in der Firma (den Projekten) löscht. Oder das ZEBRA, der "Zero Evidence But Really Arrogant". Zugegeben, die Einordnungen der Eigenschaften sind nicht besonders nett. Jedoch helfen sie Dir zunächst, die Stakeholder und ihr typisches Auftreten (also ihre Wirkung auf Dich) einzuordnen.

Und dann gibt es auch noch sogenannte "Interface Stakeholder". Diese repräsentieren ein Interface, zum Beispiel das Gesetz. Du hast mit ihnen zu tun, wenn Du ein Produkt baust, das im Umfeld der Regulatorik angeordnet ist – zum Beispiel im medizinischen Bereich oder bei Versicherungen und Banken.

Typische Herausforderungen im Umgang mit Stakeholdern

In der Zusammenarbeit mit Stakeholdern gibt es häufig eine ganze Menge an Herausforderungen, die im Umgang mit diesen auftreten.

Wenn Du Product Owner bzw. Produktverantwortlicher bist, kennst Du das Thema der Priorisierung sicherlich. Ein Stakeholder hat möglicherweise eine andere Idee der Priorisierung des Product Backlogs als Du. Hinzu kommen weitere Stakeholder, die möglicherweise wiederum andere Priorisierungsideen haben. Oftmals widersprechen sich die Priorisierungen der Stakeholder untereinander, insbesondere wenn Du die Priorisierungen in 1:1-Gesprächen klären möchtest.

Eine andere Herausforderung ist das fehlende Empowerment von Dir als Product Owner, und damit eine geringere Ownership, die Du auf das Produkt hast. Während der Scrum-Guide eine sehr simple Regelung trifft, erwähnt er gleichzeitig, dass die Ausprägung des Product Owners von Organisation zu Organisation variiert. Den "einen PO", der vollständig empowered ist, gibt es also nicht. Vielleicht teilst Du Dir die Produktverantwortung noch mit einem Product Manager? Oder Du bist in einer Gruppe von mehreren Product Ownern unterwegs, die an einem Produkt arbeiten? Jeder Kontext, sowohl aus Sicht der Organisation als auch vom Produkt her gesehen, ist daher unterschiedlich. Und dies bringt Herausforderungen im Selbstverständnis der Product Ownership mit sich.

All diese Themen multiplizieren sich häufig. So vielleicht auch bei Dir und Deiner Organisation? Ein großer Wunsch unter Product Ownern ist es, eine bessere Zusammenarbeit auf Augenhöhe zu erreichen. Dies ist die dritte große Herausforderung, die viele Product Owner verspüren.

Stakeholder Map: Hypothesen validieren

Die Stakeholder-Map ist ein sehr bekanntes Werkzeug, um Deine Stakeholder einordnen zu können. Abb. 1 zeigt beispielhaft eine 4-Felder-Matrix [1].

Unterschieden wird hierbei nach der Macht/Einfluss, die der Stakeholder im Unternehmen hat, sowie dem Interesse am Produkt. Daraus ergeben sich die folgenden Handlungsschritte:

Binde den Stakeholder in die Standard-Kommunikation ein, wenn er wenig Interesse am Produkt hat und auch wenig Einfluss in der Organisation.
Versuche die Bedürfnisse des Stakeholders herauszufinden und zu treffen, wenn er recht wenig Interesse am Produkt hat, aber großen Einfluss in der Organisation (potenzieller Multiplikator).
Halte ihn sehr intensiv über die Produktentwicklung auf dem Laufenden, wenn er ein großes Interesse am Produkt, aber wenig(er) Einfluss in der Organisation hat (ebenfalls Multiplikator).
Binde ihn sehr eng ein, manage ihn gut, kümmere Dich um seine Bedürfnisse, wenn er ein großes Interesse am Produkt hat und viel Einfluss in der Organisation.

Die Stakeholder-Map ist nur ein Abbild Deiner Zuschreibungen und Interpretationen dessen, wie Du die Stakeholder erlebst. Daher ist es wichtig, diese Zuschreibungen als Hypothesen abzubilden, und die Hypothesen regelmäßig zu (in)validieren. Auch muss die Stakeholder-Map regelmäßig gepflegt werden, da sich Interesse am Produkt und Einfluss in der Organisation ändern können.

Beachte den "Stakeholder-Map-Bias": Durch die einfache Einordnung könntest Du versucht sein, die gebildeten Hypothesen als gegeben anzunehmen und dabei möglicherweise ein schlechtes Bild, das Du vom Stakeholder hast, noch zu verstärken. Hier ist eine selbstkritische Reflektion wichtig. Der regelmäßige Kontakt zum Stakeholder hilft, die eigenen Biase erst gar nicht entstehen zu lassen oder zumindest reflektieren zu können.

Versuche ebenfalls Stakeholder, die sich im Hintergrund bewegen und zunächst nicht sichtbar sind, zu identifizieren. Dies gelingt am besten durch das regelmäßige Gespräch mit den Stakeholdern und das gezielte Erfragen von weiteren Personen in der Organisation, die Interesse am Produkt haben könnten.

In eine gute Beziehung investieren

Wir haben bereits gesagt, dass Stakeholder auch nur Menschen sind. Wenn Du auf die Arbeitsbeziehung mit Deinem Team schaust, dann gibt es dort vermutlich zwischen Euch eine gute Zusammenarbeit. Warum also nicht auch in eine gute Zusammenarbeit mit dem Stakeholder investieren? Hierzu sind beide Seiten gefragt. Und es kann hilfreich sein, wenn Du den ersten Schritt machst. Hier sind also ein paar Beispiele, die der Verbesserung der Arbeitsbeziehung zu Deinem Stakeholder dienen.

Verabrede Dich auf einen (virtuellen) Kaffee oder ein Feierabend-Bier: Je nach Level und Zugänglichkeit des Stakeholders ist es ratsam, sich mit ihm auf einen Kaffee oder Feierabend-Bier zu verabreden. Damit wird der Kontext – es geht jetzt nicht um die nächsten Features im Produkt – gesetzt. Dabei ist es wichtig, auch über Privates zu sprechen. Vielleicht teilt Ihr gemeinsame Hobbys, habt beide eine Familie und findet so Gemeinsamkeiten, über die es sich auszutauschen lohnt? Je mehr Ihr voneinander wisst, desto eher erreicht Ihr eine gemeinsame Ebene, bei der Ihr einander als (sympathische) Menschen wahrnehmt. Über die Zeit entsteht somit Vertrauen zwischen Euch.
Ist eine gute Vertrauensbasis erst einmal geschaffen, lässt sich auch besser über die Arbeit sprechen. Wir sollten also den Glaubenssatz annehmen, dass Stakeholder auch nur Menschen sind. Es wird uns dann nicht schwerfallen, zu realisieren, dass Stakeholder ebenfalls persönliche Ziele, Träume und Wünsche haben. Vielleicht haben sie aber auch Ziele, die ihnen vorgegeben sind, zum Beispiel durch den eigenen Chef oder den Rest der Organisation? Mit einer guten und etablierten Vertrauensbasis wird es Euch nicht schwerfallen, über solche Ziele und Wünsche zu sprechen.
Bleibe jedoch zunächst auf der Ebene des Stakeholders: Welche Ziele und Wünsche hat er? Wie wirken sich die aktuellen Unternehmensziele auf seine Arbeit aus? Finde es mit der neu gewonnenen Vertrauensbasis zwischen Euch heraus. Arbeite mit offenen Fragen. Sei zunächst auf seiner Ebene. Öffne Dich zwischendurch, indem Du auch mal von Deinen Wünschen und Zielen sprichst – jedoch so, dass Dein Redeanteil deutlich kleiner ist, als der des Stakeholders.

Gespräche mit Stakeholdern strukturieren

Stakeholder haben oftmals wenig Zeit. Da der Tag in "Manager's schedule" unterteilt ist, ist es schwierig, den Stakeholder für ein längeres Gespräch zu fassen zu bekommen. Umgekehrt ist es vielleicht so, dass der Stakeholder gerne auch mal zwischen Tür und Angel eine Idee für ein Feature unterbringen möchte. Dagegen hilft ein wirksames Mittel: Charmant einbremsen. Mache den Stakeholder darauf aufmerksam, dass er eine gute Idee hat. Nur ist jetzt zwischen zwei Meetings kein guter Zeitpunkt, um gut darüber sprechen zu können. Schlage ihm stattdessen den gemeinsamen Blick in Euer beider Kalender vor. Wo könnt Ihr einen 30-60-Minuten-Termin vereinbaren? Es ist wichtig, dass Du hier souverän die Gesprächsführung behältst. Stakeholder mögen souveräne Menschen, denn das signalisiert für beide Seiten Zusammenarbeit auf Augenhöhe. Dabei gehst Du in die Führung und Verantwortung: Die Verantwortung für die Eintragung eines Termins nebst einer guten und klaren Agenda im Termin. Klarheit bei Dir selbst ist dabei das Wichtigste: Mache Dir klar, was Dein/Euer Weg im Team für das Produkt ist. Sei Dir klar, dass Du verhandlungs- und kompromissbereit sein solltest, wenn Du einen guten Umgang mit Deinen Stakeholdern erreichen möchtest.

Schaut Euch also im Termin die vom Stakeholder gewünschten Punkte genau an. Bereite Dich dabei gut vor. Natürlich kann es auch sein, dass ein Stakeholder gute und sinnvolle Ideen hat. Du solltest es nicht von vornherein ausschließen, denn damit stellst Du Dich über Deinen Gesprächspartner. Wie kann solch ein kurzes Treffen sinnvoll strukturiert werden? Hier ein paar Ideen:

Screensharing mit Notizen: Wenn Ihr Euch trefft, dann lasse immer in einem Screenshare Notizen mitlaufen. Ganz egal ob auf einem virtuellen Whiteboard oder in Eurem Wiki. Notiere all das Besprochene mit. So habt Ihr beide sofort im Überblick, ob Ihr den jeweils anderen gut verstanden habt.
Lean Coffee: Eine Agenda kann eine starke Struktur haben oder ein sehr einfaches Lean-Coffee-Format. Sammelt zu Beginn des Treffens alle Punkte, die Ihr besprechen wollt, in einer Liste oder auf einigen Post-its. Priorisiert kurz gemeinsam die Reihenfolge. Und dann legt nach dem Konzept Todo/Discussing/Done mit jedem Punkt los. Für jeden Diskussionspunkt gibt es einen festen Timer, z. B. 5 Minuten. Prüft nach jedem Timer, ob Ihr an dem Punkt noch weiter sprechen wollt oder nicht. Es hat sich dabei etabliert, noch einen Abschnitt "Action Items" einzusetzen, an denen besprochene Actions festgehalten werden und wer von Euch sich darum kümmert (und ggf. bis wann).
Mehrere Stakeholder zusammenbringen: Du hast das Gefühl, dass von mehreren Seiten ähnliche Punkte oder Wünsche an der gleichen "Ecke" der Software hereinkommen? Dann sind bilaterale Gespräche zwischen Dir und dem jeweiligen Stakeholder vielleicht keine gute Idee. Schlage souverän vor, dass für diesen Wunsch ein Mini-Workshop abgehalten werden sollte, da auch andere Stakeholder ähnliche Wünsche geäußert haben und Ihr das gemeinsam priorisieren müsst.
Auch hier ist es wichtig, Souveränität auszustrahlen: Es ist Deine Verantwortung, den Workshop zu initiieren, die Agenda zu gestalten (ggf. mit Unterstützung des Scrum Masters/Agile Coaches) und eine klare Zielsetzung zu definieren. Realisiere, dass nicht gleich ein mehrtägiger Workshop eingeplant werden kann. Vielleicht reichen auch schon 2 oder 4 Stunden für die erste Koordination.
Eine gute Vorbereitung ist immens wichtig: Nimm den Stakeholdern Arbeit ab, indem Du ihre Wünsche jeweils vorbereitend notierst und auf ein gemeinsames Whiteboard bringst. So spart Ihr Euch auch einiges an Zeit.
Liberating Structures für mehr Struktur:Liberating Structures sind sogenannte Mikrostrukturen, die Du unter anderem auch in Besprechungen einsetzen kannst. Je nach Problemstellung gibt es verschiedene dieser Mikrostrukturen, die miteinander gekoppelt werden können. Eine Mikrostruktur ist jeweils in Einzelschritte unterteilt. Diese Strukturen können Dir helfen, Deine Stakeholder-Gespräche besser zu führen [2].

Verhandlungsgeschick verbessern

Deine Aufgabe ist es, souverän die Geschicke des Produkts zu lenken. Dich auf die Product Roadmap zu fokussieren und dabei wenig "Störfeuer" von außen zuzulassen. Grundsätzlich möchte ich Dir die Technik des Reframings empfehlen: Was wäre, wenn Deine Stakeholder keine gefühlten "Störer" sind, sondern "Partner in Crime" für Euer Vorhaben, nämlich das gemeinsame Produkt? All die Tipps in diesem Artikel sollen Dir helfen, dass Ihr Euch als Verbündete für Euer gemeinsames Ziel seht.

Da Deine Stakeholder wenig Zeit haben, werden sie es lieben, Dir zuzuhören.

Manchmal – und häufiger als wir denken – ist es jedoch notwendig, sich gegenseitig auszuverhandeln. Die Entwicklungs-Kräfte, die uns zur Verfügung stehen, sind rar, und in einer Iteration ist nun eben mal nicht immer ein großer Schwung möglich. Zumal auch weitere Punkte wie Bugfixing, Abbau von Technical Debts, Product Discovery und Anderes auf dem Programm stehen.

Für die Verhandlung empfehle ich Dir die SCIPAB-Methode, bestehend aus folgenden Schritten [3]:

Situation: Was ist die Situation, vor der Du stehst?
Complication: Welche Veränderung ist wichtig, welcher Demand hat Einfluss auf die Situation?
Implication: Was sind die Auswirkungen, wenn wir jetzt nichts tun?
Position: Klar und prägnant formuliert: was sollte getan werden? Hier wird prägnant aus strategischer Sicht dargestellt.
Action: Welche konkreten Aktionen müssen erfolgen?
Benefit: Welchen Benefit bringen die unter Position und Action genannten Punkte ein?

Da Deine Stakeholder wenig Zeit haben, werden sie es lieben, Dir zuzuhören. Deine Argumente für das, was Du am Produkt erreichen möchtest, werden strukturiert und klar hervorgebracht und sind für den Stakeholder auch strategisch nachvollziehbar.
Versuche, Dein nächstes Gespräch mit Deinem Stakeholder in dieser Form zu strukturieren. Die Methode eignet sich insbesondere, wenn es darum geht, dass Du bestimmte Punkte für das Produkt durchsetzen möchtest, der Stakeholder jedoch ein wichtiges Wörtchen mitzureden hat (z. B. weil er Sponsor des Budgets ist).

Neben dem SCIPAB-Modell kann ich Dir noch das Harvard-Verhandlungsmodell empfehlen [4,5]. Im Kern geht es bei allem darum, nicht einfach nur "Nein" zu sagen. Denn dadurch findet keine Anschlusskommunikation statt. Versuche, den Ball am Laufen zu halten!

Priorisierungs-Methoden, die Dir helfen

Eine gute Priorisierung im Product Backlog zu finden, ist nicht einfach. Während es eine ganze Menge an Priorisierungs-Techniken gibt, möchte ich Dir hier exemplarisch einige Werkzeuge vorstellen, die Dir insbesondere in der Priorisierung von Stakeholder-Wünschen helfen.

Bewege Dich in der Welt der Stakeholder: Es ist wichtig, die Welt der Stakeholder zu verstehen. Hast Du einen Manager vor Dir, der eher in Finanzthemen denkt und Begriffe wie Verzögerungskosten gut einordnen kann bzw. selbst nutzt? Dann könnte Weightest Shortest Jobs First (WSJF) eine gute Priorisierungstechnik sein. Versuche zu verstehen, was den Stakeholder umtreibt, welche Wünsche und Ziele er hat. Und wähle dann eine passende Priorisierungstechnik aus, die ihm entgegenkommt. So erleichterst Du nicht nur das gemeinsame Gespräch, sondern begibst Dich souverän auf Augenhöhe mit Deinem Stakeholder.
Was ist, wenn es Wünsche von mehreren Stakeholdern gibt? Wie bereits zuvor erwähnt, kann es wichtig sein, die 1-zu-1-Ebene zu verlassen und stattdessen Workshops und Meetings zu organisieren, an denen mehrere Stakeholder teilnehmen. Dies ist insbesondere bei Workshop-Methoden wie User Story Mapping oder Event Storming (Domain-driven Design) der Fall. Auch wenn es terminlich schwierig scheint, mehrere Stakeholder an einen Platz zu bekommen, kann es auch in Bezug auf die Priorisierung hilfreich sein. Eine sehr alte, aber immer noch gute Priorisierungsmethode ist hierbei "Buy a feature". Jeder Stakeholder bekommt die gleiche Menge Spielgeld und kann dieses Spielgeld (verdeckt) auf die Features als Investition verteilen. Über die Summierung der Invests für jedes einzelne Feature bekommt Ihr gemeinsam eine gute Rangreihenfolge heraus.
Sprint-Planung taktisch betreiben: Manchmal kann es sinnvoll sein, die Sprint-Planung etwas taktischer aufzustellen. Sogenannte "Happy Features" sind kleine Features, die nicht weh tun, aber Stakeholder zufrieden stellen. Dein Stakeholder denkt nur in Erweiterungen in der Nutzeroberfläche anstatt größeren Refactorings oder Schnittstellen-Features? Mit kleinen "Happy Features", die einer Iteration beigemischt werden, machst Du diesen Stakeholder zufrieden. Wichtig hierbei ist jedoch: Verliert Eure Roadmap fürs Produkt nicht aus dem Auge! Zu viele "Happy Features" machen vielleicht die vielen Stakeholder zufrieden, führen aber nicht unbedingt zu einem besseren Produkt. Hier hilft es, gemeinsam darüber zu sprechen und Verständnis dafür zu erreichen, warum die Produkt-Ziele mittelfristig erfüllt werden müssen. Schließlich wollt Ihr beide ja erfolgreich sein – das versteht auch der Stakeholder. Wird der Stakeholder bei der Erarbeitung der Produkt-Ziele passend mit eingebunden, sind später auch weniger Widerstände zu erwarten.

One more thing: Schwierige Gespräche simulieren

Um die Beziehung zum Stakeholder zu verbessern, ist es wichtig, mit all den vorher dargestellten Tipps ins "kalte Wasser" zu springen und ins Tun zu kommen. Über eine regelmäßige Reflektion – Du darfst hierzu auch gerne den Stakeholder direkt zur Zufriedenheit mit Eurer Kommunikation befragen – kannst Du Dich Stück für Stück verbessern.

Wem das noch nicht reicht oder wer zunächst eine kleine Trockenübung gestalten möchte, dem sei das fantastische Spiel "Meeting Creatures" empfohlen. Mit diesem kannst Du schwierige Gesprächsrunden üben. Es eignet sich zum Beispiel gut für eine Übung im gesamten Team, bei dem eine Person in die Rolle eines Stakeholders mit bestimmten charakterlichen Eigenschaften schlüpft. Das Spiel bringt eine ganze Reihe dieser Charaktereigenschaften mit, zum Beispiel eine Person, die permanent auf ihr Smartphone schaut oder ständig die Diskussion zu ihren Punkten dreht etc. [5]

Fazit

Wir haben uns nun tief in das Feld des Stakeholder-Managements gewagt. Die Impulse sollen Dir helfen, einen besseren Umgang mit den Stakeholdern zu finden, ihre Ideen und Wünsche gut integrieren zu können und dennoch nicht auf die Lenkung der Produkt-Roadmap zu verzichten.

Ich wünsche Dir großartigen Erfolg bei der Verbesserung Deiner Zusammenarbeit mit Deinen Stakeholdern!

Quellen