Was unterscheidet einen Amateur von einem Profi?
Professionelle Scrum Master übernehmen Verantwortung für Scrum. Sie sehen ihre Aufgabe nicht nur in der Moderation von Meetings unter der Annahme, dass die Entwickler dies nicht selbst könnten. Vielmehr sehen sie ihre Rolle darin, sicherzustellen, dass das Scrum Team effektiv arbeitet. Sie helfen dem Team, Ziele zu setzen. Sie unterstützen das Team auch beim Verfolgen dieser Ziele und helfen, schnell aus Misserfolgen und Feedback von Stakeholdern zu lernen.
Diese Professionalität zeigen sie auch in der Retrospektive, indem sie folgende Fehler vermeiden:
Fehler 1: Die Sprint-Retrospektive fällt aus
Es gibt viele Gründe, die Sprint-Retrospektive einmal ausfallen zu lassen:
- Nicht alle Mitglieder des Teams können teilnehmen.
- Es bleiben nur 30 Minuten Zeit für die Sprint-Retrospektive, bevor das All-Hands-Meeting der Geschäftsleitung beginnt.
- Es ist der Weihnachtssprint und das Team arbeitet eh nicht wirklich.
In diesen Situationen wäre es bequem, die Retrospektive auf den nächsten Sprint zu verschieben.
Ich spreche hier aus Erfahrung. Zu Beginn meiner Scrum-Master-Karriere habe ich das auch so gemacht. Rückblickend würde ich mich in diesen Situationen als Schönwetter-Scrum-Master bezeichnen. Es ist bequem, für Scrum einzustehen, wenn die Umstände angenehm sind. Murren allerdings die Mitglieder des Teams, weil Stefan und Susanne nicht an der Retrospektive teilnehmen können, und wollen deshalb die Retrospektive ganz ausfallen lassen? Oder hat die Geschäftsleitung den Termin für die Retrospektive überbucht und es bleibt keine Zeit für eine Retrospektive? Oder befindet sich das Team gerade im Weihnachtssprint und ist mehr auf Geschenke als auf Verbesserungen fokussiert? Dann scheint das Wetter nicht mehr so schön. In dieser Situation ist Mut gefordert. Es geht darum, für Scrum einzustehen. Zusätzlich muss ein Weg gefunden werden, wie sich das Team auch in diesem Sprint verbessern kann. Das unterscheidet für mich einen Profi von einem Amateur. Wie im Sport. Ein Profi geht auch zum Training, wenn es regnet.
Und darum geht es in Scrum:
Es ist nur eine kleine Verbesserung nötig. Dafür in jedem Sprint. Ausnahmslos.
Als professioneller Scrum Master übernimmst du die Verantwortung für die stetige Verbesserung des Teams.
Noch zwei Tipps, wenn die Zeit für die Sprint-Retrospektive in diesem Sprint knapp werden sollte:
- Tipp 1: Nutze während des Sprints eine Feedback-Box. Stelle eine Box neben der Tür auf mit der Aufschrift „Feedback für den Sprint“. Während des Sprints kann jedes Teammitglied dort seine Beobachtungen hinterlegen. In der Sprint-Retrospektive sparst du dir dadurch die Zeit, erst alle Beobachtungen zu sammeln.
- Tipp 2: Nutze als Format für die Sprint-Retrospektive das Perfection-Game. Dabei handelt es sich um eine einfache und schnell durchführbare Variante, eine Retrospektive durchzuführen. Wie es funktioniert, erkläre ich am Ende dieses Videos:
Was uns zum nächsten Fehler bringt:
Fehler 2: Stakeholder werden nie zur Sprint-Retrospektive eingeladen
Nachdem du diesen Fehler gelesen hast, sind vielleicht sofort die Alarmglocken angesprungen.
Zurecht. Du kennst den Scrum Guide, der besagt:
„Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlaufen ist.“
Stakeholder in die Sprint-Retrospektive einzuladen, scheint nicht zu „das Scrum Team überprüft“ zu passen. Und damit liegst du zunächst richtig. Ich denke, für Scrum Master, die am Anfang ihrer Karriere stehen, ist diese Regel hilfreich. Eine Sprint-Retrospektive, an der nur das Scrum Team teilnimmt, ist einfacher zu moderieren. Es ist leichter, für die Sicherheit zu sorgen, dass wirklich jeder im Team seine Meinung äußern kann, ohne verurteilt zu werden. Es ist auch einfacher, über Themen zu sprechen, die über die Grenzen des Scrum Teams hinausgehen.
Allerdings beschreibt der Scrum Guide die Verantwortung eines Scrum Masters so:
„Der Scrum Master ist ergebnisverantwortlich für die Effektivität des Scrum Teams.“
Für mich steht die Effektivität über der Regel, dass nur Mitglieder des Scrum Teams an der Sprint-Retrospektive teilnehmen dürfen. Wir sollten auch nicht vergessen, dass wir als Scrum Master der Organisation dienen. Eine unserer Aufgaben ist es, Barrieren zwischen Stakeholdern und dem Scrum Team zu beseitigen.
Und dafür kann der geschützte Rahmen der Sprint-Retrospektive genutzt werden.
Neue Wege zu beschreiten, unterscheidet einen professionellen Scrum Master von einem Amateur. Bei allen Regeln und Empfehlungen sollten wir nie vergessen, worum es im Kern agiler Softwareentwicklung eigentlich geht:
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.“
Wenn du deinem Team helfen möchtest, kannst du einige Schritte unternehmen. Ziel ist es, die Barrieren zwischen Stakeholdern und dem Scrum Team zu beseitigen. Ich teile gerne mein bewährtes Vorgehen mit dir.
- Liste alle Personen auf, die entweder Interesse am Produkt haben oder Einfluss auf das Team ausüben.
- Erstelle dann ein Koordinatensystem. Die eine Achse beschreibt den Grad des Interesses am Produkt, die andere den Grad des Einflusses auf das Team.
- Im nächsten Schritt entscheidet ihr gemeinsam im Team, wo die gefundenen Personen aus Schritt 1 am besten einzuordnen sind.
- Zum Schluss unterteilt ihr das Koordinatensystem in vier Quadranten. Diese geben euch einen Anhaltspunkt, wen ihr einmal zu einer gemeinsamen Sprint-Retrospektive einladen könntet.
Meine Empfehlung: Ladet „Verborgene“ und „Promotoren“ ein.
Kommen wir zum letzten Fehler, den Amateure in der Sprint-Retrospektive begehen:
Fehler 3: Verbesserungen werden nicht umgesetzt, sondern kommen nur ins Verbesserungsbacklog
Wenn ich einen Satz im Scrum Guide ändern könnte, dann diesen:
„Das Scrum Team identifiziert die hilfreichsten Änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich in Angriff genommen. Sie können sogar ins Sprint-Backlog für den nächsten Sprint aufgenommen werden.“
(Ich habe auf scrumguides.org bereits einen entsprechenden Vorschlag eingereicht. Mal sehen, ob er berücksichtigt wird. Wünscht mir Glück!)
Was ich als missverständlich empfinde, ist die Aussage: „Sie können sogar ins Sprint-Backlog für den nächsten Sprint aufgenommen werden.“ Ich verstehe, dass nicht jede Verbesserung ins Sprint-Backlog aufgenommen werden muss. Das Scrum Team kann in der Sprint-Retrospektive auch Arbeitsvereinbarungen (Working Agreements) oder die Definition of Done für das Produkt direkt anpassen.
Dennoch wünsche ich mir, dass der Scrum Guide hier präziser wird und betont, dass Verbesserungen sofort in Angriff genommen werden sollten. Bei komplexer Arbeit – sei es in der Produktentwicklung oder in der Team- bzw. Organisationsentwicklung – erkennen wir Arbeit, Probleme und Lösungen oft erst, wenn wir die Arbeit ausführen. Das ist das Wesen komplexer Arbeit. Der beste Ansatz, um dieser Komplexität zu begegnen, ist empirisches Arbeiten. Ein Aspekt der Arbeit sollte so isoliert werden, dass er klein genug ist, um schnell Fortschritte zu erzielen. Gleichzeitig sollte er groß genug sein, um dafür Feedback zu erhalten. Anschließend geht es darum, nicht länger zu zögern. Es ist wichtig, diesen ersten Schritt zu tun. Nach kurzer Zeit sollte man den Fortschritt transparent machen. Dann sollte man um Feedback bitten.
Ideen zur Verbesserung lediglich im Verbesserungsbacklog zu sammeln, steht dem entgegen.
Deshalb mein Tipp:
Am Ende der Sprint-Retrospektive solltet ihr euch auf eine kleine, sofort umsetzbare Verbesserung einigen. Bei der Priorisierung, welche Verbesserung die wichtigste ist, hat mir in der Vergangenheit immer eine Score-Karte geholfen.
Mit Score-Karten kann dein Team die möglichen Auswirkungen der Verbesserung (auf einer Skala von 1 bis 5) bewerten:
- Die Moral des Teams
- Den Wert für den Kunden
- Die Zusammenarbeit mit den Stakeholdern
- Die Qualität des Produkts
Die Verbesserungsidee mit dem größten Potenzial sollte sofort angegangen werden.
Du möchtest als Scrum Master noch einen Schritt weitergehen? Du willst Verbesserungen direkt in der Sprint-Retrospektive in Angriff nehmen? Dann schau dir gerne den Artikel „Wie du als Scrum Master dafür sorgen kannst, dass Verbesserungen aus Retrospektiven auch umgesetzt werden“ an. Darin berichte ich von meinen Erfahrungen.