Im Jahr 2019 bin ich als Scrum Master zu einem neuen Team gestoßen.
Bis zu diesem Tag hatte dieses Team noch keine funktionierende Software ausgeliefert.
Am Ende des Jahres stellten wir den Anwendern 25 neue Versionen des Produkts zur Verfügung.
Wenn du weiterliest, erzähle ich dir die ganze Geschichte. Dann erfährst du mein bewährtes 3-schrittiges Vorgehen, mit dem du ein Team unterstützen kannst, wenn du als Scrum Master neu im Team bist.
2019 wechselte ich das Unternehmen und stieß zu einem Scrum Team, welches ein Maklerprodukt in der Versicherungsbranche entwickelte.
Als Neuer im Team verbrachte ich die ersten beiden Sprints damit, die Arbeitsweise des Teams zu studieren. Dazu beobachtete ich das Verhalten der Mitglieder im Team und glich es mit den Regeln und Empfehlungen aus dem Scrum Guide ab.
Schritt #1: Verwendung des Scrum Guides als Diagnose-Tool
Hier einige der gut 100 Beobachtungen:
- Es gibt kein Ziel für den Sprint.
- Das Product Backlog ist kein Product Backlog, sondern eine Liste technischer Aufgaben.
- Das Team erstellt kein „done“-Inkrement innerhalb eines Sprints.
- Die Teammitglieder haben ein unterschiedliches Verständnis von „done“.
- Die Erwartungen einiger Stakeholder sind dem Team unklar.
- Das Team tut sich schwer, die Erwartungen der Stakeholder zu erfüllen.
- Der Product Owner fokussiert sich nicht ausschließlich auf das „Was“ und „Wozu“, sondern ist auch im „Wie“ involviert.
- Es gibt wenig wirkliche Zusammenarbeit zwischen den Mitgliedern im Team, abseits der Scrum Events.
- Es gibt kein Feedback von Kunden und Anwendern, ob das Produkt sie begeistert.
- Die Entwicklungsarbeit im Team gleicht eher einem Wasserfall und keinem „Scrum“.
- Das Daily Scrum gleicht einem typischen Statusreport, jeder berichtet, was er gestern getan hat.
- Das Product-Backlog-Refinement wurde genutzt, um die technische Umsetzung zu designen.
Am Ende der Beobachtungsphase bewertete ich, welche Abweichung den empirischen Prozess am meisten behinderte. Unser Ziel als Scrum Master ist es nicht, alle Regelverletzungen zu korrigieren, sondern die empirische Prozesssteuerung zum Leben zu erwecken. Denn Scrum Teams sind nicht automatisch erfolgreich, wenn sie die Scrum-Regeln zu 100 % befolgen, sondern dann, wenn sie das Rahmenwerk verwenden, um den Wert des Produkts empirisch zu managen. Um die schwerwiegendste Abweichung zu ermitteln, helfen uns die Scrum-Prinzipien.
Schritt #2: Die Scrum-Prinzipien helfen, das größte Problem zu ermitteln
Überprüfung und Anpassung können wir als Scrum Master nur wenig beeinflussen. Dafür ist jeder Mensch im Team selbst verantwortlich. Was wir aber beeinflussen können, sind die Transparenz der Artefakte und die Ergebnisse des Teams. Darin besteht auch die Aufgabe des Scrum Masters. Je mehr Transparenz herrscht, desto besser kann das Team die aktuelle Situation überprüfen und Anpassungen durchführen. Die Qualität der Entscheidungen wird durch den Grad an Transparenz der Artefakte bestimmt.
Das mit Abstand wichtigste Artefakt in Scrum ist das Inkrement. Es stellt die Grundlage für die Feedback-Schleife zwischen dem Team und den Anwendern dar. Deshalb bewertete ich die obigen Punkte anhand der Frage: „Welche der Abweichungen reduziert die Transparenz des Produkt-Inkrements am stärksten?“
Das Resultat lautete:
- Das Team erstellt kein „done“-Inkrement innerhalb eines Sprints.
- Die Teammitglieder haben ein unterschiedliches Verständnis von „done“.
Nun kommt der alles entscheidende Schritt. Gehst du richtig vor, versteht das Team, dass es ein Problem hat. Und ihr könnt gemeinsam Maßnahme dagegen ergreifen.
Handelst du falsch, wird das Team nicht erkennen, dass es Probleme gibt, und deine Verbesserungsvorschläge werden auf Ablehnung stoßen.
Der Schritt lautet:
Sei nicht der Lehrmeister, sondern der Helfer in der Not!
Leider denken viel zu viele Scrum Master, sie müssten ihr Team belehren, dass es etwas falsch mache. Vor einigen Tagen habe ich 14 erfahrene und langjährige Scrum Master gefragt, „welche Scrum-Master-Haltungen sie zu häufig bevorzugen“ und 5 von ihnen antworteten: „Teacher“.
Die Haltung eines Lehrers ist nicht schlecht, aber aus meiner Erfahrung in dieser Situation nicht zielführend. Menschen wollen nicht hören, dass sie etwas falsch machen. Trotzdem ist es unsere Aufgabe als Scrum Master, auf diese Missstände hinzuweisen und sie zu beheben. Diesem Dilemma begegnete ich mit einer einfachen Methode. Ich erstellte ein Quiz mit Aussagen wie:
- „Scrum Teams müssen jeden Sprint releasen.“
- „Refinement ist eine Pflichtveranstaltung für das gesamte Scrum Team.“
- „In Scrum wird das Product Backlog nach Prioritäten geordnet.“
Die Aussagen sind so gewählt, um dem Team Einblicke in das beobachtete Problem zu ermöglichen. Dann lud ich das Team zu einem Workshop ein, bei dem sie als Gruppe entscheiden sollten, ob es sich bei den Aussagen um Mythen oder Tatsachen handelte. Dieses spielerische und zugleich abstrakte Vorgehen hilft, Missverständnisse aufzudecken und, falls gewünscht, darüber zu sprechen, warum im Scrum Guide bestimmte Dinge stehen, ohne die aktuelle Arbeitsweise anzugreifen.
Im Nachgang konnte ich die alles entscheidende Frage stellen:
„Seht ihr in eurer aktuellen Arbeitsweise Abweichungen vom Scrum Rahmenwerk? Darf ich euch dabei helfen, diese zu beheben, damit wir die Vorzüge eines empirischen Produktmanagements voll ausschöpfen können?“
Das Team erkannte in dieser Situation, dass es noch Potenzial zur Verbesserung gab, und gab mir den Auftrag, dabei zu unterstützen, um am Ende jedes Sprints wirklich ein „done“-Inkrement zu haben.
Schritt #3: Verbesserungsmaßnahme gemeinsam mit dem Team umsetzen
Aus meiner Sicht bestand der größte Hebel, dieses Ziel zu erreichen, darin, das Product Backlog in Form zu bekommen. Wenn wir es schafften, den Product Backlog von einer Liste technischer Aufgaben in eine geordnete Liste von Dingen, die Nutzer wirklichen Mehrwert versprechen, zu transformieren, würden wir unserem Ziel einen entscheidenden Schritt näherkommen.
In den kommenden Wochen unternahm ich mit dem Team folgende Refinement-Aktivitäten:
- Wir interviewten potenzielle Anwender und Stakeholder.
- Wir erarbeiteten daraus echte „User“-Stories.
- Wir definierten, wann Einträge des Backlogs „done“ und nicht „done“ sind.
Um regelmäßig zu überprüfen, welche dieser Maßnahmen hilfreich waren und welche nicht, wurde die Beantwortung der Frage „Wie viele Inkremente konnten wir in diesem Sprint ausliefern?“ ein zentraler Bestandteil der Sprint Retrospektive.
Am Ende des Jahres hatten wir nicht nur 25-mal eine neue Version des Produkts an Nutzer ausgeliefert, sondern auch das Vertrauensverhältnis zwischen Kunden, Stakeholder und Product Owner verbessert. Überdies arbeitet das Team tagtäglich im „Scrum“ zusammen, wie ein wirkliches Team!
Rückblickend, denke ich, war der entscheidende Punkt für unseren Erfolg, dass ich mich als Scrum Master nicht als Berater begriffen habe. Nicht als jemand, der nur von der Seitenlinie aus den Spielern kluge Ratschläge zuruft. Stattdessen war ich ein vollwertiges Mitglied im Team. Jemand, der nicht davor haltmacht, selbst mit Kunden zu sprechen oder die Einträge des Product Backlogs aufzuschreiben.
Hier noch mal die drei Schritte zusammengefasst, welche ich verwendet habe:
- Schritt #1: Verwende den Scrum Guide als Diagnose-Tool.
- Schritt #2: Nutze die Scrum-Prinzipien, um das größte Problem zu ermitteln.
- Schritt #3: Setze die Verbesserungsmaßnahme gemeinsam mit deinem Team um.
Wenn du die Schritte hilfreich findest und sie auch anwenden willst, dann erstelle dir doch ein Lesezeichen zu diesem Artikel. Dann hast du sie immer griffbereit.