Agiler Adventskalender: Guter Umgang mit Stakeholdern

Viele von uns dürften es immer wieder mit Stakeholdern zu tun haben, bei denen es nicht leicht fällt, auch einmal „Nein“ zu sagen. Genau mit so einer Situation beschäftigen wir uns im heutigen Beitrag im Agilen Adventskalender:

Wie  kann ich zum Stakeholder „Nein“ sagen, ohne ihn vor den Kopf zu stoßen?

Wider die Featuritis

Die Kernaufgabe des Product Owners ist es, den Wert des Produkts zu maximieren. Ein Weg, der dorthin führt, ist den Anteil an Backlog Items konsequent zu reduzieren. In der agilen Community hat sich hier das Mantra “Simplicity is the art of maximizing the work not done” etabliert.

Getreu des Lean-Mottos ist es also wichtig, Verschwendung zu eliminieren. Eine Form der Verschwendung ist die “Featuritis”. Das bedeutet, dass ein Produkt eine Unmenge an Features erhält, die gar nicht benötigt werden, weil sie letztendlich nicht vom User benutzt werden.

Die Mischung macht’s

Als Product Owner hat man mit einer Vielzahl von Stakeholdern zu tun. Natürlich die Nutzer des Produkts, aber auch unternehmensinterne Stakeholder, wichtige Gremien oder externe Faktoren wie zum Beispiel in regulierten Umfeldern. Dadurch ergibt sich eine Vielzahl an Wünschen und Ansprüchen. Hier herauszufiltern, was für das Produkt sinnvoll und wichtig ist und was vernachlässigt werden kann, ist nicht einfach.

Hinter dem “Nein sagen” des Product Owners steckt somit die Orientierung (Priorisierung) nach der besten Mischung an Wünschen für das Produkt, die gemäß den Produkt-Zielen und der Produkt-Strategie den Wert maximieren.

Diese Klarheit zu erzeugen, ist die eigentliche Kommunikations-Aufgabe des Product Owners.

• Ist ein Feature wichtig für das Produkt, kann aber jetzt noch nicht realisiert werden, sondern erst in zwei Monaten?
• Wie bringe ich dem Stakeholder bei, dass die Idee zwar gut ist, aber den Wert des Produkts nicht erhöht, weil anhand von Daten davon auszugehen ist, dass die Nutzer solch ein Feature nicht haben wollen?
• Gibt es vielleicht Ideen im Product Backlog, die zwar nicht so sehr wichtig für das Produkt sind, aber dennoch als “happy features” wichtige Stakeholder zufrieden stellen, und den Freiraum ermöglichen, den ich für die kommenden wichtigen Schritte im Produkt benötige?
• Muss ich tatsächlich (Regulatorik) Sachen umsetzen, die zwar keinen Sinn ergeben, aber durch externe Faktoren wie Gesetzgebung unvermeidbar sind?

Klarheit schaffen

Wer den Stakeholder gut führen möchte, sollte also für sich selbst zunächst mal eine gute Klarheit erreichen. Hilfreich ist hierbei, Feature-Ideen nach dem Kano-Modell einzuordnen. Oder die MoSCoW-Methode der Priorisierung zu nutzen, um zu prüfen, welche Features denn tatsächlich wichtig und Wert erhöhend sind und welche nicht.

Machst Du regelmäßige Nutzerbefragungen, am besten direkt innerhalb des Software-Produkts? Die gesammelten Daten helfen nicht nur, Orientierung zu geben, sondern auch Deine Argumentation zu untermauern.

Versetz Dich daneben in die Lage Deiner Stakeholder. Warum ist Ihnen etwas wichtig? Das herauszufinden, ist nicht einfach und benötigt einen engen und kontinuierlichen Dialog. Techniken wie die 5-Why-Methode können hier helfen. Vielleicht stecken hinter den Ideen weitere (Unternehmens-)Ziele, die Euch noch nicht bekannt sind.

Geht in den Dialog

Wenn die wichtigsten Daten und Indikatoren auf dem Tisch liegen und transparent sind, dann kann der Dialog starten. Nutze Mittel wie GfK (Gewaltfreie Kommunikation) oder die Harvard-Verhandlungsmethode, um Dich mit unternehmensinternen Stakeholdern auszuverhandeln. Biete vielleicht Features in geringerer Ausprägung (also mit weniger Aufwand und damit schneller verprobbar) an. Versuch zusammen mit den Stakeholdern in Hypothesen und Experimenten zu denken.

Denn: Auch Du kannst Dich mal irren. Das ist nur allzu menschlich.

Und wenn Du dennoch einmal “Nein” sagen musst: Im Buch “50 Arten Nein zu sagen” finden sich eine ganze Menge Formulierungstipps, wie Du Deinem Gegenüber auf Augenhöhe begegnen kannst.

Du suchst einen tatkräftigen Entwicklungs-Partner und möchtest mit uns Dein Software-Vorhaben diskutieren? Dann melde dich gerne bei kontakt@mayflower.de

Oder schau Dir unser Training “Become a Product Leader” an, mit dem Du das nächste Level der Product Ownership erklimmst. Unsere Interims Product Owner helfen Euch auch direkt im Maschinenraum, zusammen mit unseren Software-Entwicklern.