06. Februar 2019

Stakeholder Management – eine komplexe Aufgabe nicht nur für den PO

SMART DEVELOPMENT NEWS 02/2019

Das ideale Scrum Team holt sich im Sprint Review Feedback von seinen Stakeholdern zu den Ergebnissen, die im abgelaufenen Sprint erzielt wurden. Daneben steht der Product Owner in einem permanenten Austausch mit den Stakeholdern, um seine Rolle als „Interessenvertreter“ der Stakeholder mit hoher Qualität wahrzunehmen.

Klingt gar nicht so schwierig, oder?

Aber dann würde bei einer wörtlichen Interpretationen der Beschreibung des Scrum Prozesses die Interaktion zwischen einem Mitglied des Development Teams und dem Management – beispielsweise seinem Gruppenleiter – auf ein paar gemeinsame Stunden im Review reduziert. Vielleicht könnte dieser Entwickler sich darüber hinausgehend auch noch ab und zu einen Rat während des Sprints einholen, aber ansonsten ist das Team ja selbstorganisiert.

Die Frage ist: Kann man wirklich davon ausgehen, dass die Zusammenarbeit zwischen Scrum Teams und dem nennen wir es Middle-Management so nach Einführung der agilen Arbeitsweise funktioniert?

Aus der Erfahrung zahlreicher Projekte – und damit sind nicht nur solche mit Pilotcharakter gemeint, sondern durchaus auch die verbreitete Verwendung von Scrum in Entwickungsprojekten – zeigt sich, dass die Praxis in der Regel sehr viel komplexer ist. Vor allem gibt es kein Patentrezept für die Zusammenarbeit zwischen Stakeholdern und Scrum Team.

Die Stakeholder in agilen Projekten

Aber nehmen wir uns doch erst noch ein wenig Zeit, um ein paar Begriffe etwas näher zu definieren. Bei Stakeholdern unterscheiden wir in erster Linie zwischen Kunden und Management. Beim Kunden könnte man dann noch etwas differenzierter den Endkunden und den Vertriebskanal betrachten. Letzterer sollte idealerweise irgendwie im Scrum Team vertreten sein, aber häufig erfolgt die Einbindung aus zeitlichen und räumlichen Gründe über die Rolle des Stakeholders. Bei den Managern, die im Kontext mit einem cross-funktionalen Scrum Team die Rolle als Stakeholdern wahrnehmen, liegt die erste Herausforderung schon allein darin, dass sie sehr zahlreich sind, wenn man alle Ebenen vom Teamleiter bis zum Top Manager eines Unternehmens oder eines Bereichs betrachtet.

Als Stakeholder Management verstehen wir die aktive Einbindung aller Stakeholder durch das Team, wobei wir uns in diesem Beitrag auf die Manager fokussieren. Wenn wir von aktiver Einbindung reden, ist durchaus eine positive und konstruktive Zusammenarbeit gemeint und keine, wo der Manager unerlaubterweise in Sprints stört oder additive Arbeitsinhalte vorgibt.

Wir gehen also davon aus, dass beide Parteien – Scrum Team und Stakeholder – agil sein wollen. Allerdings sind beide irgendwie nicht glücklich, wenn sie davon hören, dass jetzt eigentlich nur noch der Sprint Review die einzige offizielle Berührungsfläche zwischen ihnen sein soll. Natürlich versteht jeder, dass man frei entscheiden kann, wann und wo man miteinander redet, aber in der Praxis entstehen durch die Einführung von agilen Arbeitsweisen oft genau an diesen Stellen Hemmungen, weil man auch irgendwie Bedenken hat, dass durch häufige Abstimmungen mit den Vorgesetzten die Selbstorganisation verloren geht. Und in der Tat ist das ein reales Risiko. Denn aufgrund des etablierten Rollenverständnisses zwischen Chef und Mitarbeiter kann ein Rat ganz schnell zur „wahrgenommenen“ Weisung werden.

Auf der anderen Seite wäre es fachlich ein falscher Weg, wenn man im Scrum Team völlig losgelöst von den Erfahrungen der Teamleiter oder anderer Vorgesetzten arbeiten würde. Gerade in diesen Ebenen sitzt meist ein Fundus an Erfahrungen, die von sehr hohem Wert für das Unternehmen sind. Und damit auch für die Scrum Teams.

Die richtige Balance zwischen Selbstorganisation und Einbindung der Führungskräfte finden

Darum ist es in jedem Agilen Projekten immer wieder eine Herausforderung das richtige Maß und die richtige Methode für die Einbindung der (Manager-) Stakeholder zu finden.

Zwei Stellhebel helfen eine erfolgreiche Lösung zu finden:

1. Ein erfahrener Agiler Coach oder Scrum Master sollte diese Herausforderung von von Anfang an und ständig wiederkehrend thematisieren. Allein dadurch, immer wieder darauf hinzuweisen, dass es hier etwas aufzulösen gibt, wird der Blick dafür geschärft, wie die Kommunikation aus einem Scrum Team heraus mit den Managern und vice versa sinnvoll und zielführend geführt werden kann.
2. Die Kommunikation sollte möglichst systematisiert und soweit wie möglich mit dem gesamten Team geführt werden, Ansätze dafür wären beispielsweise eine partielle Teilnahme von ausgewählten Stakeholdern am Backlog Refinement oder ein „kleines Review“ während des Sprints.

Kaum habe ich es geschrieben, höre ich schon die Bedenken: „Noch ein Meeting??“ Ja, aber …. Hier geht es nicht darum, Zeit mit zusätzlichen Meetings zu verschwenden. Es geht viel mehr darum, ohnehin stattfindende Kommunikation so zu kanalisieren, dass das Team eine Chance hat, in systematischer Form daran teilzunehmen.

Unabhängig von den Details, die das Team für sich als beste Lösung identifiziert, ist eines klar: die Art und Weise der Kommunikation und Einbindung muss von Grund auf neu gestaltet werden. Das ist in jedem Fall eine komplexe Aufgabe, die viel Fingerspitzengefühl benötigt, bis sie zu einer guten Lösung gereift ist. Es ist aber enorm wichtig, an funktionierenden und vor allem gegenseitig akzeptierten Lösungen in Ihrer Organisation zu arbeiten. Ansonsten bleibt die Schnittstelle zu den Führungskräften, die ein agiles Team für eine gute Arbeit unbedingt braucht, ein permanter Konfliktherd.