Stakeholder
Der Scrum Guide nennt das Wort Stakeholder zwar, doch schweigt er dann über diese Rolle. Grund genug für uns da einmal näher drauf zu gucken.
Klar ist das Thema, dass diese Rolle außerhalb des Teams ist und was und wie ein Stakeholder ist auch super teamindividuell. Also logisch, dass der Scrum Guide dazu nichts schreibt.
Diese Folge auf YouTube: https://youtu.be/AUOpxaj2q8Y
Stakeholderkommunikation
Normalerweise lernen wir im Scrum Master Training, dass der Product Owner die Schnittstelle zwischen Team und Stakeholdern ist. ist das immer sinnvoll?
Klar der Grund dahinter ist absolut sinnvoll, schließlich sollen äußere Störungen vom Team ferngehalten werden. Da der Product Owner dies kanalisiert und entsprechend einplant entlastet dies das Umsetzungsteam sehr. Gleichzeitig möchten wir natürlich auch Stille Post vermeiden und bei der Umsetzung von Anforderungen schon sehr nahe Stakeholderkommunikationen. Es gilt ja auch Verschwendung zu vermeiden. Im Stille Post Modus wäre der Product Owner tatsächlich die Stelle der Verschwendung.
Das Team trifft auch spätestens im Review und wahrscheinlich auch im Refinement auf Stakeholder und sollte auch dort offen und direkt mit Stakeholdern kommunizieren können. Es wäre schade diese Events nicht für einen intensiveren Austausch zu nutzen.
Der Unterschied besteht darin Kontakt mit den Stakeholdern zu haben oder deren Interessen zu vertreten. Für letzteres ist der Product Owner zuständig. Da dieser auch für die Priorisierung verantwortlich ist, laufen die Arbeitsaufträge natürlich über den Kanal des Product Owners. Die Gespräche selbst können die Teammitglieder aber führen, wie sie es für richtig halten.
Es ist Aufgabe des Product Owners und des Scrum Masters die Stakeholder darüber aufzuklären, was sie eventuell damit anrichten, wenn sie Aufgaben direkt bei Teammitgliedern abgeben. Hier droht Mehrarbeit, unpriorisierte Spezialaufträge und Verschwendung. Vielen Stakeholdern ist das so nicht bewusst und sie brauchen einfach nur Aufklärung. Danach funktioniert es im Regelfall sehr gut. Auch die Teammitglieder dürfen diesbezüglich sensibilisiert werden.
Da wir so auch Stille Post vermeiden ist das Ganze natürlich eine Gradwanderung auf die wir achten dürfen.
Das Refinement
Für die jeweiligen Anforderungen der Stakeholder und Allgemein bietet es sich an die Stakeholder mit zu den Refinements einzuladen. So können sie sich informieren und auch direkt Fragen zu ihren Themen beantworten. Die Refinements werden aber nicht an den Kalender der Stakeholder angepasst, sondern bleiben Rituale, die die Komplexität reduzieren. Wenn Stakeholder beim Refinement dabei sind, empfiehlt es sich aber deren Themen als erstes zu behandeln, damit diese eventuell dynamisch aus dem Termin rausgehen können, fass sie weniger Interesse an den anderen Themen haben.
Wer ist Stakeholder?
Eigentlich jeder, der irgendwie ein Interesse am Projekt hat. Das können Familienmitglieder sein, Geldgeber, Kunden, Chefs oder Kollegen. Im Prinzip wirklich jeder. Die große Kunst ist nun die Stakeholder je nach Gruppe entsprechend richtig zu behandeln und abzuholen.
Stakeholder im Daily
Das Daily gehört dem Team zu ihrer Synchronisation. Stakeholder sind in diesem Event gern gesehen und bekommen erst einmal keine eigene Bühne. Ist das Daily früher zu Ende kann man sich natürlich gern einen Plausch mit den Stakeholdern halten oder Informationen austauschen. Es ist nicht ratsam erst einmal eine Vorstellungsrunde im Daily zu machen, da dies den Termin sprengen würde und auch nicht Sinn und Zweck davon ist. Das sollte außerhalb des Dailys passieren und kann ja auch davor stattfinden. In dem Fall wüsste dann auch jeder wer die heutigen Zuhörer im Daily sind.
Das Review
Im Scrum Guide steht explizit drin, dass dieses Ritual nicht als reine Präsentation genutzt werden sollte. Der große Vorteil liegt hier darin gemeinsam mit den Stakeholdern das Backlog an die geänderten Umweltbedingungen anzupassen. Oft ergeben sich auch neue Anforderungen aus den Dingen, die die Anwender und vielleicht auch Kunden nun sehen. Manchmal kann man sich nicht alles vorstellen, was bereits möglich ist, ehe man dies in der Hand hat. Nutzt also das Review für erfolgreiche Kommunikation.
Stakeholdermanagement
Stakeholdermanagement ist ein Bereich aus dem klassischen Projektmanagement und ist auch für Agile Projekte ganz ratsam. Übertreib es aber nicht! 😀
Das Stakeholdermanagement beschäftigt sich damit, mit welchen Personen wir alles zu welchen Themen kommunizieren, wie viel Einfluss sie haben und wie wichtig sie für das Projekt sind. Also auch die oft unterschätze Disziplin Marketing! Zudem ist es sehr gut Stakeholder zu bestimmten Themen nachschlagen zu können, wenn der Product Owner einmal nicht greifbar ist.
Wenn das Team hauptsächlich gerade Aufgaben für einen speziellen Stakeholder erledigt, dann integriere ich diesen Stakeholder gern für eine kurze Zeit im Team oder lasse ihn wenigstens in der Nähe arbeiten. Dies verkürzt Kommunikationswege und klärt Fragen sehr schnell. Auch kann der Stakeholder direkt sagen ob ihn bestimmte Lösungen gefallen oder auch nicht.
Störenfriede und Hippos in Terminen
Wenn Du Störenfriede in Deinen Terminen hast, dann gehört es zur Tätigkeit des Facilitators diese Menschen zur Seite zu nehmen und entsprechend einzeln zu betreuen um die Termine des Product Owners effektiv zu halten.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann bewirb dich gerne für unser True Leader Coaching: https://znip.academy/produkt/scrum-master-coaching/ – Durch deine Bewerbung hast du die Chance auf einen der nächsten freien Plätze.
In der Podcastfolge erwähnte Folgen zur Vertiefung:
Connecte dich gerne hier mit uns:
1 comment on “Folge 056 Stakeholder”