In Scrum gibt es bekanntlich drei Verantwortlichkeiten: Scrum Master:in (SM), Product Owner:in (PO) und Developer:in. Alle anderen werden in einen großen gemeinsamen Topf geworfen: den Stakeholder-Topf. Die Bedeutung der Stakeholder wird oft verkannt. Deswegen möchte ich ihnen diesen Blogartikel widmen.

Die Definition (wikipedia): Als Stakeholder wird eine Person oder Gruppe bezeichnet, die ein berechtigtes Interesse am Verlauf oder Ergebnis eines Prozesses oder Projektes hat.

Im Scrum-Kontext denken wir dabei zuerst an die Kunden und Nutzer, um die sich ja alles dreht. Auf den zweiten Blick wird die Liste deutlich länger: Mitarbeiter, andere Teams in der Entwicklung, andere Abteilungen im Unternehmen (Marketing, Sales…), das Management, Sponsoren, Investoren, Betriebsrat, alle möglichen Subject Matter Experts wie z.B. Experten für Datensicherheit oder rechtliche Fragen, Lieferanten… Bei einem Software-Produkt vielleicht nicht so relevant, aber entscheidend bei Hardware-Produkten: wir müssen den gesamten Lebenszyklus des Produktes im Auge haben, also auch Produktion, Betrieb, Wartung, Außerbetriebnahme. Menschen, die in diesen Lebensphasen mit dem Produkt arbeiten, haben ein berechtigtes Interesse daran und sind daher definitionsgemäß Stakeholder. All diese Personen im Blick zu haben und einzubeziehen, ist eine große Herausforderung, die man am besten als Team angeht. 

Stakeholder-Mythen

Mythos #1: Scrum kommt ohne (explizites) Stakeholder-Management aus.

Richtig ist: Es gibt zwar kein Kapitel zum Stakeholder-Management im Scrum Guide, der Begriff Stakeholder kommt aber dort 13mal vor. Stakeholder geben dem Produkt einen Sinn. Sie beeinflussen die Entwicklung entscheidend. Manche von ihnen haben sogar so viel Macht, dass sie über  das „Go/No Go“ entscheiden können, indem sie einem Vorhaben kurzerhand den Geldhahn zudrehen. 

Es gibt bewährte Praktiken aus dem Projektmanagement, die sich auch auf agile Produktentwicklungen anwenden lassen:

• Stakeholder identifizieren: Checklisten für mögliche Stakeholder
• Stakeholder analysieren und Priorisieren: Stakeholder Map zur Einschätzung von Interesse, Einfluss, Verfügbarkeit und Einstellung zum Produkt
• Stakeholder kontinuierlich einbinden: Kommunikationsplan mit Häufigkeit und Art der Kommunikation, idealer Weise durch Integration in den Scrum-Ablauf, zusätzliche Meetings und Workshops

Noch wichtiger als Praktiken sind jedoch wieder mal die Werte und Prinzipien, nach denen wir unsere Zusammenarbeit gestalten wollen: Neugierde, Respekt, Vertrauen, psychologische Sicherheit, keine Schuldzuweisungen, Offenheit, Transparenz, Feedback. Die Scrum Master:in schafft eine Umgebung, in der die Scrum-Werte beherzigt, empirisches Vorgehen verstanden und agile Praktiken gelebt werden. Das gilt auch für die Zusammenarbeit mit Stakeholdern und kann durch spezielle Training oder Workshops initiiert werden. Dabei kann man die Rechte und Verantwortlichkeiten der Stakeholder festlegen. 

Mythos #2: (Nur) die PO ist für Stakeholder zuständig.

Richtig ist: Die PO hat die Aufgabe, mit dem Produkt den maximalen Wert für Stakeholder zu erzeugen. Was Wert bedeutet, kann die PO nur mit Stakeholdern gemeinsam entscheiden. Daher ist eine Zusammenarbeit von Anfang an wichtig. Es ist ganz normal, dass Stakeholder ganz unterschiedliche Interessen haben. In einer Organisation, die agile Verantwortlichkeiten lebt, hat die PO die Verantwortung, bei Interessenskonflikten Entscheidungen über das Produkt zu treffen, damit die unterschiedlichen Interessen nicht zu einer Blockade führen. Die PO hat somit im Scrum Team eine besondere Rolle und muss „empowered“ sein, also die Akzeptanz und Unterstützung der Stakeholder genießen. Das sollte jedoch nicht dazu führen, dass nur die PO mit Stakeholdern redet. Dann könnte sie leicht zum Bottleneck werden. Das Thema ist viel zu wichtig, als das man es einer einzelnen Person überlassen könnte. Je besser das gesamte Scrum Team die Bedürfnisse der Stakeholder versteht, desto besser ist es in der Lage, passende Lösungen zu entwickeln. 

Mythos #3: Kontakt mit Stakeholdern findet (nur) im Sprint Review statt.

Richtig ist: Stakeholder-Zusammenarbeit ist von Anfang an und kontinuierlich wichtig. Es geht schon früh los bei der Erstellung von Produkt-Vision und -Zielen, mit Innovations-Workshops, bei der Modellierung von Use Cases oder der Erstellung von Story Maps. Gute Möglichkeiten für die SM, sich als Facilitator auszutoben. Am besten ist es, gleich mehrere Stakeholder zusammenbringen, damit sie sich gegenseitig kennenlernen und verstehen. Methoden wie Design Thinking oder „Buy a Feature“ (Innovation Games) kombinieren divergentes und konvergentes Denken. So entstehen neue Ideen und ausführbare Aktionen. Über die Bedeutung des Sprint Reviews als regelmäßiger „Touch Point“ mit Stakeholdern könnt ihr hier nachlesen. Darüber hinaus kann es sinnvoll sein, Stakeholder auch in das Backlog Refinement oder das Sprint Planning einzubeziehen, Das Product Backlog spielt eine wichtige Rolle als Artefakt, das (laut Scrum Guide) „transparent, sichtbar und verstanden“ ist – auch und gerade für Stakeholder. Dafür sorgt die PO. Zum besseren Verständnis kann sie zum Beispiel Zuversichts-Intervalle im Backlog angeben: wie schätzen wir die Wahrscheinlichkeit, das bestimmte Items im aktuellen Release umgesetzt werden können?

Stakeholder Management ist Politik

Ob wir wollen oder nicht: Stakeholder sind häufig nicht vollständig in das agile Denken und Vorgehen einbezogen und ticken eher traditionell. Sie möchten (oder müssen aufgrund ihrer Aufgabenbeschreibung) ihre Interessen durchsetzen, wenn es sein muss auf Kosten anderer. Sie stellen Fragen, die sich in einer komplexen Umgebung nicht mit Sicherheit beantworten lassen: „Wann kommt Feature XY?“, „Warum dauert das so lange?“, „Könnt ihr Feature Y nicht noch mit ins Release aufnehmen? Das kann doch nicht so schwierig sein!“ Sie üben Druck aus und sind sich oft nicht über die Folgen im Klaren (siehe dazu meinen Blog Mythbusting: Schätzungen werden überschätzt). Sie erkennen nicht, dass auch sie durch konstruktive Zusammenarbeit einen Beitrag zum Erfolg des Produktes leisten müssen. Um mit dieser Gemengelage fertig zu werden, bewährt sich die Aufgabenteilung zwischen PO und SM: die PO konzentriert sich auf die inhaltlichen Aspekte des Produktes und auf Informationen, die für Produktentscheidungen relevant sind. Die SM hat den Blick auf die Art der Zusammenarbeit und die Atmosphäre, wirkt als Facilitator, gibt Feedback und initiiert Verbesserungen.

Stakeholder-Management ist (über)lebenswichtig

Als ob das nicht schon anspruchsvoll genug wäre, möchte ich den Blick noch erweitern. Produkte können während ihres Lebenszyklus Schaden anrichten. Die Bewältigung der Klimakrise und anderer Nachhaltigkeitsthemen erfordert die Berücksichtigung sozialer, politischer und ökologischer  Systeme. Ein Unternehmen und letztendlich die gesamte Menschheit kann nur überleben, wenn wir diese Aspekte bei Produktentwicklungen berücksichtigen. Dies erfordert einen systemischen Denkansatz beim Stakeholder-Management, über die Grenzen einzelner Funktionsgruppen hinaus. Wir können mit Stakeholdern gemeinsam überlegen, welche Nachhaltigkeitsthemen für die Produktentwicklung relevant sind, welche Auswirkungen sie haben, und wie wir damit umgehen wollen: Klimaschutz, Gesundheitsschutz, Digitalisierung, Unternehmenskommunikation… Zukunftsmusik? Ja, und wir können den Wandel, der sowieso stattfindet, dazu nutzen, uns neu zu positionieren.