OK, vom vorigen Beitrag wissen nun, dass ein guter Scrum Master ganztags ausgelastet ist, um agile Themen in seiner Organisation voranzutreiben. Er hat dabei immer seine 3 Sichtbereiche, in denen er seine agile Kompetenz einbringen und Themen vorantreiben kann. Doch auf welcher Basis kann sich ein Scrum Master sicher sein, das Richtige zu tun?
Scrum Master für mehrere Teams
Zunächst einmal stellen wir uns die Frage, für wen der Scrum Master aller zuständig sein kann. Rein auf Team-Ebene betrachtet, kann ein guter Scrum Master 2-3 Teams behandeln und damit sein Pensum gut erfüllen. Voraussetzung dafür ist, dass er und die Organisation damit zufrieden sind, diese Rolle nur auf Team-Ebene auszuführen, was – vereinfacht formuliert – mit folgenden Daily Tasks erledigt wäre:
- Ereignisse organisieren & moderieren
- Timeboxes einführen & überprüfen
- Hindernisse von Team-Mitgliedern aus dem Weg räumen oder ihnen dabei helfen, diese selbst zu lösen
- Verbesserungen gemeinsam mit dem Team vorantreiben
Das Team wird gemeinsam mit seinem Scrum Master sehr wahrscheinlich über sich hinauswachsen – weitreichendere oder langfristige Änderungen in der Organisation sind allerdings nicht zu erwarten.
Scrum Master für ein Team
Fokussiert sich ein Scrum Master auf nur ein Team und dafür auch auf eine bereichsübergreifende agile Transformation, performt nicht nur das Team großartig, sondern erreicht auch damit die Organisation Dinge, die bis dahin nur schwer vorstellbar waren.
Meine Empfehlung lautet daher:
ein bestimmter Scrum Master
für ein bestimmtes Team
zu einem bestimmten Zeitpunkt
in einer bestimmten Organisation
Sollten Scrum Master noch immer nicht die vielfältigen Aufgaben ihrer Rolle erkannt haben, so brauchen sie eigentlich nur lernen hinzuschauen und aktiv zuzuhören:
- dem Product Owner (oder dem Team von Produkt-Verantwortlichen)
- dem Entwicklerteam (alle die Tasks und Aufgaben abarbeiten)
- den Entwicklungspraktiken des Teams (wie sie arbeiten wollen)
- der Einbindung anderer Teams (innerhalb und außerhalb der Abteilung)
- die Organisation außerhalb des Teams (alle anderen Bereiche)
Vor allem zertifizierte Scrum Master übersehen oft diese zwischenmenschlichen Ereignisse und sollen besser heute als morgen damit anfangen, bewusster hinzuhören und zuzuschauen und dabei versuchen, folgende Fragen zu beantworten:
Was macht mein Product Owner?
Um die Effektivität des POs zu verbessern, hilft man diesem am besten beim Pflegen des Product Backlogs und des Release Plans. Nur er soll die Priorisierung der Items sowie den zeitlichen Ablauf des Releases vornehmen – natürlich in Abstimmung mit dem Team, aber es braucht halt dafür einen Entscheider.
- Ist der Product Backlog am aktuellen Stand und entsprechend priorisiert?
- Sind alle Anforderungen und Wünsche von allen Stakeholdern (intern + extern) im Backlog erfasst?
Zur Erinnerung: Der Backlog ist emergent – daher können Dinge auch plötzlich auftauchen! - Hat der Product Backlog eine überschaubare Größe? Um eine überschaubare Anzahl an Items pflegen zu können, ist es wichtig, weiter “unten” priorisierte Anforderungen nur grob zu formulieren und am Ende der Liste ohnehin nur mehr Epics definiert zu haben. Ein zu genauer Detaillierungsgrad wäre sogar kontraproduktiv (man spricht hier von “overanalyze”) und wäre gar wieder ein Schritt zurück zu klassischen Ansätzen.
Zur Erinnerung: Anforderungen werden sich aufgrund laufender Gespräche zwischen Entwicklerteam, PO und Stakeholder ändern! - Können irgendwelche Anforderungen (speziell jene weiter oben am Beginn des Backlogs) besser beschrieben werden hinsichtlich den INVEST-Kriterien (independent, negotiable, valuable, estimable, small, testable) für User Stories?
- Weiß der Product Owner Bescheid über technische Schulden (technical debt) und wie man sie vermeidet? Das Ergänzen von automatisierten Tests und Refactoring der Definition of Done (DoD) für jedes Backlog Item könnte hierbei schon mal rasch helfen.
- Ist der Backlog eine Informationsdrehscheibe, welche für alle Stakeholder sichtbar ist?
- Wenn für das Management des Backlogs ein digitales Tool zum Einsatz kommt, ist zu hinterfragen, ob dieses auch richtig verwendet wird und für die Benutzer einen Mehrwert generiert? Oft wird versucht bei automatisierten Management Tools viel zu automatisieren und wenig manuell beizusteuern, was aus der gewünschten Drehscheibe mit Inputs von Scrum Master und Product Owner eher ein starres Gefüge ohne manuellen Inputs generiert.
- Kann mit ausgedruckten Karten/Items mehr Einbindung geschaffen werden?
- Versuche mit Visualisierungen (zB große, selbst gemalte Diagramme) für Verständnis und Einbindung zu sorgen und positiv beizutragen.
- Hilf dem Product Owner beim Organisieren von Backlog Items in angemessene Releases.
- Wissen alle Stakeholder und das Team Bescheid, ob der Release Plan die Wirklichkeit überlebt, basierend auf der aktuellen Velocity (zB Story Points pro Sprint)?
- Hat der Product Owner den Release Plan nach dem letzten Sprint Review angepasst? Nur wenige Product Owner planen den Release jedes Sprints neu, wenn das getestete Produkt-Inkrement rechtzeitig ausgeliefert wird. Wichtige, bisher nicht relevante Arbeit kann bis zum nächsten Release auftauchen! Der Mike Cohn-Style für das Product bzw. Release Burndown (als “done” anerkannte Items im Zuge des Reviews) hat sich hier schon oft bewährt, welcher frühe Entdeckungen von Abweichungen des Scopes sowie des Plans ermöglicht.
Was macht mein Scrum/Entwickler-Team?
Verbringen alle Team-Mitglieder eine gute, positiv durchlebte Zeit und haben ein gutes Gefühl dabei, bei dem was sie machen? Folgende Punkte sollten für das Team klar sein:
- Klare Ziele: Erwartungen und Regeln wahrnehmbar – Ziele erreichbar und auf Fähigkeiten ausgerichtet
- Konzentration und Fokussierung (bei gleichzeitig beschränkter Aufmerksamkeit)
- Weniger persönliche Befangenheit, mehr Team-Bewusstsein
- Verzerrte Zeit-Wahrnehmung (jeder hat damit andere Erfahrungen)
- Direktes und rasches Feedback (Erfolg und Fehler werden sofort sichtbar, sodass bisheriges Verhalten umgehend angepasst werden kann)
- Gutes Gleichgewicht zwischen Können und Herausforderung (die Aufgabe soll weder zu leicht noch zu schwierig sein)
- Ein Gefühl für persönliche Kontrolle über die Situation oder Aktivität
- Mögen sich die Teammitglieder untereinander, hängen schon mal einfach so beisammen und feiern gemeinsam Erfolge?
- Teammitglieder verantworten untereinander hohe Standards und ermutigen sich gegenseitig diese einzuhalten
- Gibt es Issues, welche das Team nicht diskutiert, weil sie unbequem sind? Unangenehme Fragen zu stellen und Dinge anzusprechen, um daraus annehmbare Issues zu machen, sollte Aufgabe eines Moderators oder guten Scrum Masters sein.
- Retro ist nicht standardisiert: Versuche verschiedene Formate und Locations für die Sprint Retrospektive
- Das Team fokussiert sich auf Akzeptanzkriterien? Führe manchmal Mid-Sprint Checks durch um die AKs der committeten PBIs zu überprüfen.
- Ist der Sprint Backlog das Spiegelbild dafür, was das Teams gerade macht? Unterbrechungen und Ablenkungen, die nicht zum Sprint Ziel beisteuern, sind eindeutig Impediments!
- Sind alle Team Tasks geschätzt und das Taskboard up to date?
- Sind alle Artefakte für das Selbst-Managen von Teams (Taskboard, Sprint Burndown Chart, usw.) sichtbar für das Team und werden zweckmäßig von diesem angewandt?
- Sind diese Artefakte ausreichend geschützt vor Mikro-Management?
- Melden sich die Team-Mitglieder freiwillig für Tasks?
- Gibt es Technical Debt Repayment Items (um Issues zu identifizieren, die die Team Velocity minimieren) die im Backlog erfasst oder zumindest dem PO kommuniziert wurden?
- Lassen die Team-Mitglieder ihre Job-Position außerhalb des Team-Büros?
- Fühlt sich das gesamte Team selbst-verantwortlich für Testen, User Dokumentation, usw.?
Wie machen sich unsere Entwickler-Methoden?
- Gibt es in der Entwicklungsumgebung einen “Push to Test”-Button, sodass jeder (aus dem eigenen oder fremden Team) erkennen kann, wenn etwas fehlerhaft läuft (dies wird oft durch das xUnit Framework wie JUnit oder NUnit erreicht)?
- Gibt es ein angemessenes Gleichgewicht zwischen automatisierten End-to-end System-Test (Funktionstests) und automatisierten Unit Tests?
- Verwendet das Team sowohl für die Funktionstests als auch für die Unit Tests die gleiche Sprache wie auf der Entwicklungsumgebung (besser als Script-Sprachen oder Playback-Tools, die nur wenige aus dem Team bedienen können)?
- Hat das Team die nützliche Grauzone zwischen Systemtest und Unit Test entdeckt?
- Macht sich der Continuous Integration Server (CIS) bemerkbar wenn Regression Failures auftreten?
- Sind alle Tests bei den Ergebnissen des CIS ersichtlich?
- Hat das Team schon die Vorzüge von Continues Design als Alternative zur ‘Big Design Up Front’ entdeckt? Refactoring bedeutet, die internen Strukturen zu ändern, ohne das Verhalten nach außen zu ändern. Refactoring sollte immer dann gemacht werden, wenn duplizierter Code auftaucht, komplexe Conditional Logic vorhanden ist (lange Methoden mit viel Einrückungen), wenig aussagende Methodennamen (identifiers) verwendet wurden usw. Das ganze sollte mit automatisierten Tests abgedeckt werden. Werden Löcher in der Testabdeckung nicht gestopft und Refactoring erst mit erheblicher Verzögerung gemacht, werden diese zu Technical Debts.
- Beinhaltet die Definition of Done for jedes “funktionale” Produkt Backlog Item voll automatisierte Testabdeckung und Refactoring? Ohne dem wird es schwierig werden, ein potentiell lieferbares Produkt (PSP) nach jedem Sprint bereits zu stellen – viele Praktiken aus XP (eXtreme Programming) würden sich dafür ebenfalls eignen.
- Praktizieren die Entwickler zumindest zeitweise Pair Programming? PP kann die Code-Qualität und -Wartung erheblich verbessern und damit Bugs deutlich reduzieren. Es stellt das Team vor neuen Aufgaben: Wo ist meine persönliche Grenze? Dauert das ganze nicht zu lange (Quantität vor Qualität)? Deshalb sollte PP nicht erzwungen werden – besser wäre ‘Lead by Example’: initialisiere ‘Paired Workdays’ mit einigen aus dem Team. Manche werde ab dann nur mehr so arbeiten.
Wie macht sich unsere Organisation?
- Funktioniert der Info-Austausch und die Koordination außerhalb der Teams innerhalb der Organisation? Scrum of Scrums (SoS) ist nur ein Weg um dies zu erreichen. Denke deshalb daran, auch Botschafter in andere Team-Dailys zu senden.
- Sind für diese Team-übergreifenden Koordination Leute zuständig, welche sich selber “die Hände schmutzig” machen?
- Treffen sich alle Scrum Master regelmäßig und arbeiten gemeinsam an einer ‘Impediments List’ des Unternehmens?
- Wo sind die Unternehmens/Organisations-Impediments sichtbar? Im Idealfall auf der Wand des Entwicklungs-Abteilungsleiter. Können die Kosten in Geldeinheiten, Lost Time to Market, Lost Quality oder Lost Customer Opportunities quantifiziert werden?
- Ist die Organisation eine der wenigen, bei denen der Karriereweg mit den kollektiven Zielen deiner Teams kompatibel ist? Oder ist der Karriereanreiz eher durch viel programmieren oder Architektur-Arbeit auf Kosten von Testen, Testautomatisierung oder Benutzerdokumentation gegeben?
- Hilfst du mit eine Learning Organization zu erstellen?
- Ist die Organisation durch Pressearbeit oder andere unabhängige Quellen als einer “der besten Arbeitsplätze” anerkannt oder ein Vorreiter in seinem Umfeld?
Viele dieser Fragen muss man sich natürlich mehr als einmal stellen und versuchen, den auf Basis der Antworten eingeschlagenen Weg einzuhalten. Der Scrum Master muss sich selbst auch immer neu erfinden, denn wie schon die Scrum Alliance sagt:
Fear ist your Friend!
Zum Schluss noch ein persönlicher Tipp: Sobald man erkennt, welche Änderungen man als Scrum Master herbeiführen kann und welche Ausmaße diese haben können, könnte man es mit der Angst oder zumindest mit Unsicherheit ob des ungewissen Weges zu tun bekommen. Ich sehe dieses Gefühl aber eher als Zeichen, dass man auf dem richtigen Weg unterwegs ist. Mut ist ja immerhin einer der 5 Kernwerte von Scrum ;)
