Stakeholder-Management, aber wie?

Jeder Product Owner kennt die Herausforderungen im Stakeholder-Mangement und stellt sich wahrscheinlich die gleichen Fragen wie ich:

• Wie soll ich das anstellen?
• Wie bekomme ich eine akzeptable Priorisierung hin?
• Wie kommen wir auf einen gemeinsamen Nenner?

Leider sind diese Fragen nicht so pauschal zu beantworten, denn es gibt hierbei viele Faktoren, die reinspielen. Wie zum Beispiel die Struktur der Firma, die verschiedenen Ebenen, aus denen die Stakeholder kommen, welcher Typ Mensch die Stakeholder sind, etc. Um nur ein paar zu nennen …

Patentrezept?

Dieselben Schwierigkeiten stellen sich in jedem Projekt aufs Neue und erfordern manchmal tatsächlich auch ein bisschen Fingerspitzengefühl. Die Erfahrung, die ich gemacht habe, ist nicht mit der Brechstange vorzupreschen, sondern sich die Situation anzuschauen und Ruhe zu bewahren.

Es gibt viele Ansätze und im Internet findet man ebenfalls viele verschiedene Seiten mit den unterschiedlichsten Methoden. Dennoch gibt es kein Pauschalrezept à la „Mach das so und das funktioniert immer!“, sondern es kommt tatsächlich auf das Umfeld an.

Manchmal wird einem die Lösung auf dem Silbertablett geliefert und manchmal muss man etwas härter und länger dafür kämpfen. Jedoch kommt man irgendwann an den Punkt, an dem es auch beim letzten Widerständler „klick“ macht. So auch in einem meiner Projekte, in denen ich tätig sein durfte. Und daran möchte ich euch teilhaben lassen.

Stakeholder-Management: ein Erfahrungsbericht

Ich hatte das Vergnügen in ein bereits seit Längerem existierendes Projekt zu kommen und wurde dort natürlich vor viele schwierige Aufgaben gestellt. Eine davon war das  Stakeholder-Management.

Die Situation die ich vorgefunden habe war verfahren und leicht angespannt. Es gab keinen Product Owner, weshalb die Stakeholder ihre Anforderungen selbst geschrieben haben. Das führte dazu, dass die Devs von den Stakeholdern genervt waren und sich ebenfalls über die ständige Änderung der Priorisierung und des Commitments beschwerten. Die Stakeholder haben sich im Gegenzug darüber beschwert, dass die Devs nicht rechtzeitig liefern würden.

Aber egal, ich möchte zunächst mit dem Grundsetting des Projekts beginnen. 

Die Umgebung

Bei dem Projekt handelte es sich um ein E-Commerce-Projekt in einem stark hierarchisch geführtem Unternehmen. Es gab viele Stakeholder, die sich alle um verschiedene Projekte innerhalb der Firma kümmern mussten. Die meisten Stakeholder hatten keine oder kaum Erfahrung mit Softwareentwicklung und wussten deshalb häufig nicht was auf sie zukommt. Und alles war sehr managementgetrieben.

Soviel zum Umfeld in dem Projekt. Und nun zu den Bedingungen innerhalb des Dev-Teams.

Das Innenleben

Es handelte sich um ein gemischtes Team an Entwicklern: teilweise beim Kunden direkt angestellt, teilweise Devs von uns. Darüber hinaus gab es einen Scrum Master und keinen Product Owner.

Das Team versuchte, einen Scrum-Prozess zu etablieren und in zweiwöchentlichen Sprints zu arbeiten. Das Ergebnis war sehr ernüchternd, weil es schlicht unmöglich war, ein Sprintziel zu erzeugen. Auch das Commitment des Teams wurde regelmäßig durch ungeplante Anforderungen befeuert und zunichtegemacht. Die Anforderungen kamen eher wasserfallmäßig herein, als dass man sie ordentlich hätte planen können. 

Eine Priorisierung des Backlogs war nahezu unmöglich, da die Stakeholder auch nicht miteinander kommunizierten und so meistens der „gewonnen“ hat, der am lautesten schrie. Das alles und das Umfeld führten dazu, dass der Scrum-Prozess eher zu einem „WaterScrumBan“-Prozess mutierte.

Ein Lösungsansatz?

An dieser Stelle komme ich ins Spiel.

Ich fand diesen Scherbenhaufen vor und habe mir das Ganze erst mal in aller Ruhe angeschaut, Leute interviewed und bei diversen Meetings als Chicken teilgenommen. Somit konnte ich mir ein eigenes Bild schaffen und in aller Ruhe einen Weg finden, um diese Situation etwas besser in den Griff zu bekommen.

Also, was haben wir letztendlich unternommen? Zunächst einmal wollte ich von diesem WaterScrumBan-Dingens weg und habe vorgeschlagen, lieber auf Kanban zu wechseln, da dieser Prozess in so einem Umfeld besser handhabbar ist.

Nachdem der Prozess dann irgendwann auf Kanban umgestellt wurde, kam natürlich die Frage nach der Priorisierung auf. Es kam am Anfang regelmäßig vor, dass die „ToDo“-Spalte leer war und die Devs nach mehr Arbeit geschrien haben. Also habe ich mir überlegt, wie man die Stakeholder dazu bekommt, miteinander zu reden. Ich sprach mit dem Projektleiter und dem Scrum Master vom Kunden, ob es möglich wäre, ein regelmäßiges Meeting mit allen Stakeholdern zu etablieren. 

Gesagt, getan. Es wurde ein wöchentliches Meeting mit allen Stakeholdern ins Leben berufen. Zu Beginn dieser Meetings herrschte sehr viel Schweigen und wir (der Scrum Master, der Projektleiter und ich) mussten gebetsmühlenartig den Zweck dieser Meetings wiederholen und ihn den Stakeholdern einimpfen.

Gut Ding will Weile haben

Die ersten paar Wochen war der Effekt dieser Meetings gleich null und wir waren damit beschäftigt einen Weg zu finden, um den Stakeholdern zu vermitteln, welche Benefits dieses Meeting für sie hat. Nach und nach kam immer mehr Kommunikation in dieses Meeting und die Stakeholder haben tatsächlich angefangen, miteinander zu reden. Besser noch: zu diskutieren!

Mittlerweile laufen diese Meetings so ab, dass zunächst jeder Teilnehmer einen kurzen Überblick über sein laufendes Projekt gibt. Danach wird auf das Kanban-Board geschaut, ob noch Themen in der ToDo-Spalte sind und ob diese noch richtig priorisiert sind. Dann wird ein Blick auf die Roadmap geworfen und die Stakeholder müssen ihre nächsten Themen pitchen und in gemeinsamer Arbeit entsprechend in die ToDo-Spalte des Kanban-Boards priorisieren. Sprich die Agenda ist wie folgt gegliedert:

• Projekt-Überblick: Status des Projekt und was ist noch zu tun
• Blick aufs Board um Ticketpriorität in der ToDo-Spalte anzupassen
• Blick auf die Roadmap: Was war, was ist und was kommt demnächst
• Pitch der neuen Storys und gemeinsames priorisieren

Erfolg?

Wie oben bereits geschrieben hat es zwar ein bisschen gedauert bis auch der Letzte den Sinn und Zweck dieses Meetings verstanden hatte. Aber der Effekt, den wir jetzt dadurch haben, ist beachtlich. Wir haben keinen Leerlauf mehr und auch das Aufkommen von „plötzlich“ wichtigen Stories ist nahezu verschwunden.

Ebenfalls haben wir es geschafft, dass Stakeholder mittlerweile auch ausserhalb dieses Meetings anfangen miteinander zu reden und auch ausserhalb dieser Runde Stories in die ToDo-Spalte packen. Es läuft zwar immer noch nicht komplett rund, denn wir müssen noch gelegentlich jemandem auf die Finger klopfen. Aber im Großen und Ganzen kann man sagen, dass es definitiv um +1 besser läuft als vorher.

Es ist Ruhe bei den Devs eingekehrt, sie können nun ungestört Tickets abarbeiten. Auch die Stakeholder sind glücklich, weil sie mittlerweile wissen, dass sie ihre Story spätestens nach einer Woche haben, wenn sie in der ToDo-Spalte ist.

Fazit

Auch das ist jetzt kein Patentrezept, wie es mit dem Stakeholder-Management klappt. Aber es soll Euch zeigen, wie man es angehen kann und dass es immer einen Weg gibt, um die oben beschriebenen Probleme in den Griff zu bekommen.

Solltet ihr weiterhin Fragen zum Stakeholder-Management oder anderen Themen haben könnt ihr gerne jederzeit auf mich oder meine Kollegen von Mayflower zukommen.

In diesem Sinne weiterhin viel Erfolg im täglichen Wahnsinn – und immer den Kopf oben lassen.