Drohen uns jetzt Scrum-Silos? So stoppst du diesen beunruhigenden Trend frühzeitig und initiierst echte Zusammenarbeit mit Stakeholdern

Woher kommt der Name „Scrum“?

Scrum geht auf die Arbeit von Professor Hirotaka Takeuchi und Professor Ikujiro Nonaka zurück. In den 1980er Jahren untersuchten sie die Produktentwicklung von Unternehmen wie Fuji-Xerox, Canon, Honda, NEC, Epson, Brother Industries, 3M, Xerox und Hewlett-Packard. Das Ergebnis formulierten sie in ihrem Paper „The New New Product Development Game“: Der Produktentwicklungsprozess innovativer Unternehmen ergibt sich aus der ständigen Interaktion eines handverlesenen, multidisziplinären Teams, dessen Mitglieder von Anfang bis Ende zusammenarbeiten. Diesen Prozess nannten sie den Rugby-Ansatz, und daher rührt der Name „Scrum“.

Nochmal in anderen Worten:

Scrum fußt auf der Idee der funktionsübergreifenden Zusammenarbeit.

Diese interdisziplinäre Zusammenarbeit war das Gegenteil dessen, was in den meisten Unternehmen zu dieser Zeit vorherrschte und auch heute noch häufig zu finden ist. Noch drastischer formuliert: Mit Scrum werden die „Funktionssilos“, die in Unternehmen herrschen, eingerissen. Mit Funktionssilos meine ich, wenn Menschen derselben Funktion – etwa „Softwareentwickler“, „Tester“ oder „Designer“ – in unterschiedlichen Abteilungen voneinander getrennt werden.

Aus der Geschichte sollten wir lernen und uns davor hüten, Unternehmen zu gestalten, in denen zwar nun keine Funktionssilos mehr vorherrschen – aber dafür Scrum-Silos entstehen. Ich spreche von Unternehmen, die ihre interdisziplinären Scrum Teams von den restlichen Bereichen des Unternehmens wie HR, Controlling oder Vertrieb trennen.

Versteh mich nicht falsch: Ich bin noch keinem Unternehmen begegnet, das so arbeitet, allerdings lassen Aussagen wie diese mich aufhorchen:

• „Wenn ein Stakeholder eine Frage hat, dann muss er sich an den Product Owner wenden. Gespräche mit den Entwicklern sind tabu.“
• „Im Sprint Review sind nur Entwickler vom Nachbarteam anwesend.“
• „Stakeholder haben in der Sprint-Planung und im Sprint Review niemals Zutritt.“

Ja, wir unterscheiden in Scrum klar zwischen Mitgliedern des Scrum Teams und den Stakeholdern. Das sind alle Personen, die nicht Teil des Scrum Teams sind. Und ja, wenn Vertriebsmitarbeiter Entwickler im Sprint bitten, schnell eine Änderung am Produkt durchzuführen, da der Kunde sich das unbedingt wünscht, dann sollten Scrum Master dies zum Anlass nehmen, ein Gespräch zwischen Product Owner, Entwickler und Stakeholder zu suchen und allen Beteiligten erklären, warum diese Art von „Zusammenarbeit“ nicht hilfreich ist.

Aber es bedeutet nicht, dass sich die Scrum Teams von der Außenwelt abschotten müssen, sondern dass wir die Art und Weise, wie Scrum Teams mit anderen Personen im Unternehmen zusammenarbeiten, so produktiv wie möglich gestalten sollten.

Wenn du weiterliest, verrate ich dir, wie du einen solchen Austausch initiieren kannst. Bevor wir dazu kommen, starten wir mit dieser grundlegenden Frage:

Wer sind eigentlich die Stakeholder des Produkts?

Diese Frage beantwortest du am besten mit den Mitgliedern deines Teams in einer kurzen Brainstorming-Session.

Ziel der Session ist es, eine Stakeholder-Matrix zu erstellen. Du erstellst die Matrix in vier Schritten:

1. Listet alle Personen auf, die entweder Interesse am Produkt haben oder Einfluss auf die Entwicklung des Produkts ausüben.
2. Nun erstellt ihr ein Koordinatensystem. Die eine Achse beschreibt den Grad des Interesses am Produkt, die andere Achse den Grad des Einflusses auf die Entwicklung des Produkts.
3. Im nächsten Schritt entscheidet ihr gemeinsam im Team, wo die gefundenen Personen aus Schritt 1 am besten einzuordnen sind.
4. Zum Schluss unterteilt ihr das Koordinatensystem in vier Quadranten. Diese geben euch einen Anhaltspunkt, wie ihr die Zusammenarbeit mit diesen Stakeholdern gestalten könnt.

Hier die vier Quadranten im Detail:

• Promotoren sind Personen, die ein großes Interesse am Produkt haben und einen großen Einfluss auf seine Gestaltung ausüben. Zum Beispiel Kunden, Investoren, wichtige Nutzer. Diese Personen sollten umfassend einbezogen werden, zum Beispiel, indem ihr sie zum Sprint Review und zu Refinement Sessions einladet.
• Verteidiger sind Personen, die einen erheblichen Anteil am Produkt haben und einen mäßigen oder geringen Einfluss auf das Produkt ausüben. Zum Beispiel regelmäßige Nutzer des Produkts. Diese Personen sollten regelmäßig einbezogen werden, zum Beispiel mit der Einladung zum Sprint Review oder indem ihr sie mit Produkt-Videos, Newslettern und Feedback-Umfragen über die Fortschritte informiert.
• Latente sind Personen, die einen erheblichen Einfluss auf das Produkt haben, aber nicht wesentlich daran beteiligt sind. Dazu könnte ein Teamleiter gehören, dem die Mitglieder des Scrum Teams unterstellt sind, ein Enterprise-Architekt oder UX-Researcher, dessen technische Entscheidungen vom Team befolgt werden müssen, oder ein wichtiger Kunde anderer Produkte des Unternehmens. Diese Personen sollten zufriedengestellt werden.
• Publikum ist die Gruppe von Menschen, die weder ein Interesse am Produkt haben noch Einfluss auf die Entwicklung nehmen können. Hierbei könnte es sich um jede Person in eurem Unternehmen handeln, die in keine der obigen drei Kategorien fällt. Für diese Personen sollte es ausreichend sein, sie bei Bedarf zu informieren, zum Beispiel in Form eines Artikels auf einer internen Unternehmensseite oder durch eine Pressemitteilung.

Nachdem du die aktuell bekannten Stakeholder identifiziert und klassifiziert hast, kannst du eine Zusammenarbeit initiieren.

Ich möchte zwei Beispiele dafür geben:

Beispiel 1: Wie du das Sprint Review von einer reinen Demonstration in eine Feedback-Party verwandelst

Das häufigste Problem bei Sprint Reviews?

Entweder sind die falschen Personen anwesend oder das Review besteht nur aus der Demonstration der Features.

Die Stakeholder-Matrix hilft dabei, die richtigen Personen zum Sprint Review einzuladen. Mit „richtig“ meine ich jene, deren Feedback besonders wertvoll für die Entwicklung des Produkts ist. Wie du die Demonstration in eine Feedback-Party verwandelst, erkläre ich dir jetzt. Wir nutzen dazu die Liberating Structure „Shift and Share“.

So geht's:

Vorbereitung für „Shift and Share“:

Wähle etwa drei bis fünf Einträge aus dem Product Backlog aus, zu denen euer Scrum Team gerne Feedback erhalten möchte. Für jeden Eintrag richtet ihr eine Station ein. Etwa ein Flipchart mit einigen Informationen und einen Laptop, um das Feature auszuprobieren. An jeder Station muss mindestens ein Mitglied des Teams anwesend sein, um das Feedback der Stakeholder aufzunehmen. Verseht dazu jede Station mit Zetteln, um Feedback zu erfassen.

Durchführung von „Shift and Share“:

Begrüße die Stakeholder zum Sprint Review und bedanke dich für ihre Anwesenheit. Erkläre dann die verschiedenen Stationen und erläutere den Stakeholdern, dass sie von Station zu Station gehen werden. An jeder Station haben sie die Möglichkeit, ein neues Feature auszuprobieren, Fragen zu stellen und Feedback zu geben. Fordere die Stakeholder auf, sich gleichmäßig auf die Stationen zu verteilen. In Runden von zehn Minuten bewegen sich die Gruppen im Uhrzeigersinn durch die Stationen. Achte darauf, dass an den Stationen die neuen Features nicht nur demonstriert werden, sondern von den Stakeholdern ausprobiert werden können.

Abschluss von „Shift and Share“:

Bedanke dich bei den Stakeholdern für ihr Feedback und erkläre, wie euer Scrum Team mit dem Feedback verfahren wird.

Wenn du das Sprint Review mit „Shift and Share“ gestaltest, ermöglichst du innerhalb einer Stunde viel Austausch zwischen dem Scrum Team und den Stakeholdern.

Neben dem Sprint Review bietet sich auch die Sprint Retrospektive an, um die Zusammenarbeit mit den Stakeholdern zu verbessern.

Wie das geht, erfährst du jetzt:

Beispiel 2: Wie du die Sprint Retrospektive nutzen kannst, um die Zusammenarbeit mit den Stakeholdern zu verbessern

Stakeholder in die Sprint Retrospektive einzuladen, klingt auf den ersten Blick ungewöhnlich?

Der Scrum Guide erwähnt diese Möglichkeit zwar nicht, aber nur weil der Scrum Guide etwas nicht erwähnt, bedeutet das nicht, dass es verboten ist. Wir sind ja Scrum Master und nicht die Scrum Polizei! Aus meiner Erfahrung spricht nichts dagegen, von Zeit zu Zeit auch Stakeholder in die Sprint Retrospektive einzuladen. Natürlich muss das gesamte Scrum Team zustimmen.

Ein tolles Format hierfür bietet die Meta-Retrospektive von Stefan Wolpers und Zach Bonaker.

In seinem neuen Buch „The Scrum Anti-Patterns Guide: Challenges Every Scrum Team Faces and How to Overcome Them“ beschreibt Stefan Wolpers dieses Format im Detail. Darüber hinaus verrät er viele Tipps, wie Scrum Master die verbreitetsten „Scrum Anti-Patterns“ in ihrem Team überwinden können. Ich kann dieses Buch jedem Scrum Master nur empfehlen! In diesem Artikel möchte ich dir nur die nötigen Schritte vorstellen, sodass du die Retrospektive sofort in deinem Team durchführen kannst.

Hier die Schritte:

1. Bitte die Mitglieder des Scrum Teams und die Stakeholder, sich zu mischen und paarweise zusammenzufinden. Jedes Paar bekommt nun 5 Minuten Zeit, drei Beobachtungen zur Zusammenarbeit des Scrum Teams mit den Stakeholdern zu sammeln. Jede Beobachtung soll als eigene Notiz festgehalten werden.
2. Während die Paare sammeln, nutzt du die Zeit und zeichnest eine vertikale Achse auf ein Whiteboard. Beschrifte die Enden der Achse mit „Gut“ und „Nicht so gut“.
3. Nach dieser Sammelphase stellt jedes Paar seine Notizen der Gruppe vor und platziert sie entlang der Achse.
4. Nun stellst du die zweite Achse vor. Beschrifte die Enden der Achse mit „Können wir beeinflussen“ und „Kein Einfluss“.
5. Bitte die Paare, ihre Notizen zusätzlich entlang der horizontalen Achse auszurichten.
6. Wenn sich keine Notizen mehr bewegen, überführst du das Koordinatensystem in eine Matrix.

Die Quadranten der Matrix im Detail:

• „Ran an die Arbeit“: Dies ist der Bereich, der sich unmittelbar auswirkt.
• „Weitermachen“: Hier gibt es im Moment nichts zu ändern für uns.
• „Mit dem Management besprechen“: Diese Probleme behindern die Zusammenarbeit und sollten gelöst werden.
• „Glück“: Das ist gut gelaufen, wir investieren hier keine weiteren Mühen.

Im letzten Schritt der Meta-Retrospektive unterstützt du die Gruppe dabei, umsetzbare Verbesserungen für die Beobachtungen im „Ran an die Arbeit“-Quadranten zu finden. Hier bietet sich ein Lean-Coffee-Format an.

Die Meta-Retrospektive ist eine einfache Möglichkeit, die Zusammenarbeit zwischen Scrum Team und Stakeholdern zu überprüfen und Verbesserungen zu identifizieren.

Nun wünsche ich dir viel Erfolg beim Einreißen von Silos. Seien es Funktionssilos oder Scrum-Silos.