Stakeholder effektiv in Scrum einbinden!

Was ist ein Stakeholder?

“Du bist kein Stakeholder!”, höre ich oft. Der Stakeholder als Begriff wird meist sehr eng gefasst und auf definierte Interessenvertreter und Sponsoren reduziert. So verpassen wir die Chance, die Personen mit einem Interesse an unserer Leistung mitzunehmen.

Deswegen sehe ich den Begriff des Stakeholders breiter. Ein Stakeholder ist laut Wikipedia jeder der ein “Stake”(Einsatz, Anteil, Anspruch, Erwartung oder Interesse) an der Leistung einer Firma hat.

Diese breitere Definition stellt uns vor die Herausforderung diese sehr weitgefasste heterogene Gruppe adäquat abzuholen und einzubinden.

Wo liegen die Herausforderungen im Stakeholder-Management in Scrum?

Um Stakeholder effektiv und frühzeitig in unsere Arbeit im Scrum-Team einzubinden, müssen wir sie überhaupt erst einmal kennen. Aus mangelndem Verständnis von einzelnen Personen und Personengruppen mit Interesse an unserer Entwicklung fehlt die Grundlage diese effektiv und frühzeitig einzubinden, woraus häufig Konflikte und Missverständnisse mit diesen Stakeholdern entstehen.

Wesentlich für das mangelnde Verständnis und die Empathie für die Bedürfnisse der Stakeholder ist die starke funktionale Trennung (Silos-Bildung). Dabei isolieren sich die  Bereiche meist an fachlichen oder technischen Trennlinien voneinander und entfernen sich so von einem gemeinsamen Verständnis, von dem was sie eigentlich gemeinsam schaffen wollen. Im Extremfall entfernen sich Bereiche so weit, dass sie kaum noch der Sprache der anderen Abteilung folgen können und von deren Fortschritten und Problemen nichts mehr wissen wollen. Es gibt keine gemeinsame Identität mehr als schaffende Einheit und auch keine Identifizierung mehr, mit der gemeinsam geschaffenen Leistung.

Selbst wenn man die Stakeholder kennt und ihre Bedürfnisse besser verstehen würde, so bleibt die Herausforderung, dass man nicht immer dazu aufgestellt ist, auf die Bedürfnisse der Stakeholder einzugehen.

• Entscheidungen werden zu früh getroffen, zu einem Zeitpunkt, wo die Stakeholder die Tragweite dieser Entscheidungen oft schwer abschätzen können.
• Es gibt keine belastbaren konkreten Informationen, mit denen man gemeinsam das Produkt über den gesamten Verlauf gestalten kann.
• In der Entwicklung werden Vorhaben in kleinteiligen technischen Arbeitspaketen analysiert, aus deren Lieferung weder der Fortschritt nachvollzogen, noch mitgestaltet werden kann.
• Wichtige Aspekte (wie nicht-funktionale Anforderungen und Risiken) sind zu technisch formuliert und werden nicht gemeinsam reflektiert, sodass hier Stakeholder im Verständnis keinen Einfluss nehmen können.
• Konsequenzen von ungünstigen Entscheidungen können nicht transparent aufgezeigt werden, so wie auch Risiken von zu optimistischen Kundenversprechen.

Meistens sind Stakeholder es gewohnt aus der Luft gegriffene Vorgaben zu machen. Erst aus dem Lieferdruck werden hier die Termine eingehalten und Ergebnisse müssen entstehen. Diese Deadlines erzeugen im Scrum- Team einen Konformitätsdruck zu den gesetzten Zielen und nehmen den Beteiligten den sicheren Raum, um gemeinsam realistische und nachhaltige Ziele anzugehen.

Wie binden wir in Scrum Stakeholder effektiv mit ein?

• Wer sind unsere Stakeholder? 
• Welche sind besonders kritisch und welche besonders einflussreich? 
• Welche sind bisher unzureichend abgeholt und eingebunden? 

Umso früher wir uns diese Fragen stellen und eine Übersicht der Stakeholder haben, können wir diese besser abholen und in die Ausgestaltung des Produktes integrieren. Idealerweise erstellt man eine “Stakeholder Map” nicht nur möglichst früh, sondern bindet bei der Erstellung das Scrum Team und auch Personen aus dem Umfeld mit ein. Ausgehend von dieser Übersicht kann man regelmäßig hinterfragen, zu welchen Stakeholdern wir unsere Aufstellung weiter optimieren müssen.

Eine wesentliche Frage (nicht nur für das Stakeholder-Management) ist: „Was ist das Ziel der Entwicklung des Scrum Teams?“. Ist das Ziel klar oder ist es eine diffuse, breite Sammlung an Anforderungen.

Damit wir gemeinsam und fokussiert ein Produkt entwickeln können, brauchen wir eine Ausrichtung auf ein gemeinsames Ziel. Dies kann beispielsweise durch das Schreiben einer Produktvision erreicht werden. Die Herausforderung der Ausrichtung auf ein übergreifendes, gemeinsames Ziel ist wichtig, damit wir uns mit der Vielzahl an Stakeholdern nicht immer wieder in einem „Klein-Klein“ an Einzelinteressen verlieren, sondern gemeinsam nach etwas Größerem streben. Einfach nur eine Produktvision zu schreiben reicht hierfür übrigens nicht aus. Eine einmal erstellte Produktvision dient nur zum Festhalten der aktuellen Zielrichtung. Es muss ein “lebendes” Dokument sein, das nachjustiert wird und bei diesem Prozess ist wiederum das Einbinden der Stakeholder essentiell, sonst hat das Schriftstück keinen Wert.

Mit einem fragmentierten, „technischen“ Product Backlog können wir keine Stakeholder in die Entwicklung einbinden. Ein gutes Product Backlog ist nutzerorientiert und gibt so die Möglichkeit im direkten Austausch mit potentiellen Nutzern und Stakeholdern das Produkt auszugestalten. Dazu müssen wir uns als Scrum-Team allerdings entsprechend aufstellen. Unser Ziel ist es nicht technische Aspekte zu ignorieren, wir stellen aber technische Gesichtspunkte nur in den Dienst der Wertschöpfung für den Nutzer.

Ohne einen strategischen Ausblick und die Fähigkeit Stakeholder früh mit einzubeziehenentstehen unreflektierte Entscheidungen und unüberprüfte Hypothesen werden zu Grundannahmen für die weitere Entwicklung. Wir müssen gesprächsfähig sein und bleiben. Zu Beginn des Vorhabens, auch wenn es zu dem Zeitpunkt nur eine sehr grobe Road Map mit vielen Ungewissheiten gibt, und auch im gesamten Verlauf der Entwicklung, wenn sich die Road Map immer mehr konkretisiert.

Ist es einmal soweit, dass sich in der Entwicklung “Silos” gebildet haben oder mit bestimmten Stakeholdern keine Kommunikation erfolgt, gibt es auch kein gemeinsames Bild von dem zukünftigen Produkt und damit wird es unmöglich es gemeinsam zu gestalten. Um das zu verhindern, gibt es die Schlüsselrolle des Sprint Reviews als gemeinsame Plattform zur Bestandsaufnahme, Austausch und Nachjustierung.

Damit diese Sprint-Zeremonie ihrer Rolle auch gerecht wird, muss schrittweise die Einbindung von Stakeholdern im gemeinsamen Austausch gelernt werden. Aus der informellen Einbindung erster Stakeholder kann das Feedback für die Einbindung weiterer Personengruppen gezogen werden und das Format an dem wachsenden gemeinsamen Verständnis optimiert werden.

Häufige Fragen der Stakeholder betreffen die Zukunft der Entwicklung. Was können wir in den nächsten 8 Wochen erwarten? Wann wird das minimale Feature Set fertiggestellt sein? Wie teuer wird das strategische Feature XY geschätzt?

Damit wir die Erwartungen managen und diese Fragen beantworten können, brauchen wir eine Möglichkeit zu planen und diese Planung laufend zu überprüfen. Über Agiles Forecasting können wir hier verbindlich aussagefähig werden, wobei es nicht nur um die Benennung von Zeiten und Umfängen geht, sondern auch darum, wie belastbar die Zuverlässigkeit unserer Aussagen über die Zukunft sind.

Damit wir Risiken, Unbekannte & Unsicherheiten früh ausräumen und damit wir einen Rahmen zur gemeinsamen Ausgestaltung des Produktes vorfinden, nutzen wir in Scrum ein iteratives und inkrementelles Vorgehen. Wir splitten große Vorhaben in vereinfachte Anwendungsfälle, um aus deren Umsetzung ein klareres Bild über Herausforderungen und wirkliche Bedürfnisse der Nutzer zu bekommen. Ohne vernünftig geschnittene Anforderungen ist eine gute gemeinsame Gestaltung des Produktes nicht möglich.