Was unterscheidet Scrum von Zombie-Scrum?
Die Mitglieder des Teams sitzen nicht wie Zombies in den Scrum Meetings und hoffen auf ein schnelles Ende. Die Meetings erzeugen als Resultate nicht nur weitere Meetings. Sondern die Mitglieder im Team entwickeln die Ergebnisse und sich kontinuierlich weiter. Indem sie frühzeitiger funktionierende Software liefern. Indem sie regelmäßiger Feedback von ihrem Kunden erhalten. Was ihnen ermöglicht, die Prinzipien und Werte hinter Scrum zu leben. Schlussendlich übernehmen sie mehr Verantwortung für ihre Rolle in Scrum.
Das unterscheidet Scrum von Zombie-Scrum.
Wie kannst du deinem Team im Kampf gegen Zombie-Scrum helfen?
Da Zombie-Scrum als Krankheit weitverbreitet ist, stelle ich diese Frage häufig. Als Antwort erhalte ich:
Der Product Owner muss „empowered“ sein. Er muss das Product-Backlog in gutem Zustand halten. Das Team muss seinen Wert kennen und messen.
Dabei wird ein Punkt häufig übersehen. Ein Scrum Team besteht doch in der Regel aus einem Product Owner, einem Scrum Master und aus 6 Entwicklern.
Warum nicht dort anfangen, wo zahlenmäßig der größte Hebel liegt?
Hilfst du den Entwicklern, einen Aspekt ihrer Arbeit zu verbessern, dann multipliziert sich dieser Effekt mit sechs. Hilfst du dagegen dem Product Owner, einen Aspekt seiner Arbeit zu verbessern, multipliziert sich dieser Effekt nicht. Wenn du dir jetzt denkst: So einfach ist die Rechnung nicht. Bei der Verbesserung von Teamarbeit gilt eben nicht eins plus eins ist gleich zwei, sondern es kann durchaus drei ergeben. Teamarbeit ist komplex. Und ein Product-Backlog, das in einwandfreiem Zustand ist, kann somit einen viel größeren Hebel darstellen. Da hast du recht. Gleichzeitig ist es jedoch auch so, dass ein perfektes Backlog nichts nützt, wenn die Arbeit im Sprint nicht fertig wird.
Wo wir wieder bei den Entwicklern sind.
Deshalb mein Rat: Beginne deinen Kampf gegen Zombie-Scrum bei den Entwicklern.
Ich starte damit, ihnen ihre wirkliche Verantwortung in Scrum aufzuzeigen. Leider habe ich in den letzten Jahren zu viele Teams gesehen, in denen die Entwickler ihre eigentliche Verantwortung in Scrum nicht kannten. Sie dachten, es sei Scrum, wenn sie der Product Owner im Sprint-Planning mit Aufgaben füttert. Wenn der Scrum Master sie einzeln über ihren Fortschritt ausfragt. Und sie glaubten, dass technische Verbesserungen keinen Platz im Sprint haben (unter uns: Das ist Zombie-Scrum.).
Ganz im Gegenteil:
Entwickler übernehmen eine große Verantwortung für Scrum. Sie sind verantwortlich dafür,
- einen Plan für den Sprint zu erstellen: das Sprint-Backlog;
- Qualität durch die Einhaltung einer Definition of Done einzubringen und
- täglich ihren Plan zur Erreichung des Sprint-Ziels anzupassen.
Und wenn du sie dabei unterstützen willst, dann habe ich drei Tipps für dich.
Allerdings – bevor wir zu den Tipps kommen – noch eine Warnung:
Niemand mag es, bevormundet zu werden. Das möchten wir weder in unserer Kindheit noch in der Schule und ganz bestimmt nicht im Arbeitsleben. Deshalb sind die Tipps als Workshops oder Vorschläge formuliert. Damit kannst du den Entwicklern ein Angebot machen, wie sie noch mehr Verantwortung übernehmen und Scrum kontinuierlich verbessern können.
Nun zu den Tipps:
Tipp 1: Nutze „All Hands All Ears“ zur Erstellung des Sprint-Backlogs
Wir alle kennen die Herausforderung beim Schmieden von Plänen.
Wenn sich nicht alle einbringen und beteiligen, sinkt die Wahrscheinlichkeit der Umsetzung rapide. Es herrscht kein Commitment.
Seitdem ich mit Scrum Teams arbeite, kenne ich dieses Problem.
Das Jira-Board wird auf die Leinwand projiziert. Der Scrum Master tippt. Gleichzeitig beschreibt ein Entwickler die Tasks. Dies funktioniert jedoch nur auf den ersten Blick. Die Entwickler scheinen sich auf einen Plan zu einigen. Am nächsten Tag findet Thomas es jedoch nicht mehr sinnvoll. Er geht anders vor als besprochen. Das führt zu Unmut beim Rest des Teams. Deshalb habe ich angefangen, nach anderen Formaten zur Erstellung des Sprint-Backlogs zu suchen. Ich habe viel ausprobiert, Task-Break-Down mit Sticky-Notes oder an einem Architektur-Diagramm. Allerdings habe ich den bisher strukturiertesten Ansatz von Steffi Götten vor einigen Jahren am Scrum Day gelernt. Sie nennt es „All Hands All Ears“. Ich habe das Verfahren seither einige Male genutzt. Es hat immer zu einem gemeinsamen Verständnis geführt. Auch hat es eine gemeinsame Sprache unter den Entwicklern gefördert.
Mit diesen drei Schritten kannst du „All Hands All Ears“ auch nutzen:
Schritt 1: Zu einem gegebenen Product-Backlog-Eintrag überlegt sich jeder Entwickler die To-dos, die er erledigen würde, um diesen Eintrag umzusetzen, und notiert sie auf Sticky-Notes. Diesen Schritt macht jeder für sich, ohne sich mit den anderen auszutauschen.
Schritt 2: Nun geht es reihum und jeder Entwickler hat die Möglichkeit, eine der folgenden vier Aktionen auszuführen:
- eine Sticky-Note in der Umsetzungs-Task-Liste des Product-Backlog-Eintrags ergänzen,
- eine der Sticky-Notes in der Umsetzungs-Task-Liste löschen,
- eine Verständnisfrage zu bereits gelegten To-dos stellen,
- ein To-do in der Liste ersetzen, wenn man es anders machen würde.
Schritt 3: Das Team wiederholt Schritt 2 so lange, bis jeder alle seine To-dos gelegt hat und keine Verständnisfragen mehr offen sind.
Jetzt kennst du „All Hands All Ears“.
Wenn die Entwickler beim nächsten Mal Schwierigkeiten haben, einen Plan für den Sprint zu erstellen, schlage doch diese Methode vor. Sie sollten einen Plan finden, an den sich auch jeder halten möchte. So kann jeder die Verantwortung für das Sprint-Backlog übernehmen.
Tipp 2: Verwende „Now, Next, Later“, um die „Definition of Done“ sichtbar zu machen und zu verbessern
Neues Feature oder Verbesserung der Softwarequalität?
Am Anfang ihres Sprint-Plannings stellen sich viele Scrum Teams diese Frage. Ist die Frage berechtigt oder handelt es sich nur um ein Missverständnis?
Im Jahr 2017 unterstützte ich als Scrum Master ein Team, welches eine Anwendung betreute, die „historisch gewachsen“ war. Was eine nette Umschreibung dafür ist, dass die Anwendung keine Testabdeckung hatte. Es wurden hier und da manuelle Tests gemacht und vor einem Release hat das ganze Team einige Tage lang das System auf Herz und Nieren geprüft. Dass dieses Vorgehen problematisch ist, war den Entwicklern bewusst. Und deshalb war es nicht verwunderlich, dass es Thema einer der ersten Sprint-Retrospektiven war. Der Wunsch der Entwickler war es, mehr automatische Tests zu haben. Deshalb formulierten wir dies als Retrospektiven-Verbesserung. „Neue Features müssen automatisiert getestet sein.“ Daraufhin warf der Product Owner sofort ein, dafür sei im nächsten Sprint keine Zeit, wir hätten bereits andere Dinge geplant.
In dem Moment, in dem ich dem Product Owner zustimmte, realisierte ich, dass ich einen Fehler gemacht hatte.
Was bedeutet meine Zustimmung langfristig? Wenn jede Verbesserung in den Product-Backlog wandert, dann konkurriert sie zwangsläufig mit jedem Feature, das sich Kunden wünschen. Und du kannst dir bestimmt vorstellen, wohin das führt. Im schlimmsten Fall werden Verbesserungen nie eingeplant und im besten Fall irgendwann in ferner Zukunft. Und was bedeutet das dann für das Produkt? Qualitätsverbesserungen werden aufgeschoben. Oder drastischer formuliert: Qualität ist verhandelbar.
Und das ist ein Missverständnis.
Qualität ist in Scrum nicht verhandelbar. Der Umfang eines Features ist es, aber nie dessen Qualität. Deshalb müssen Retrospektiven-Verbesserungen nicht in das Product-Backlog aufgenommen werden. Stattdessen können sie direkt als Verbesserung in der Definition of Done festgehalten werden. Im Sprint-Planning schauen sich die Entwickler die Definition of Done an. Sie überlegen, welche Aufgaben im Sprint nötig sind, um die Qualitätsanforderungen für einen Eintrag des Product-Backlogs zu erfüllen. Im Beispiel wäre es: „Tests definieren, umsetzen und automatisieren“. Diese Arbeit gilt für jeden Product-Backlog-Eintrag, den das Team im Sprint bearbeitet.
Warum erzähle ich dir diese Geschichte? Ich habe an diesem Tag verstanden, warum die Aufteilung zwischen „Was“ und „Wie“ ein wichtiges Prinzip in Scrum ist. Es zeigt sich in den beiden Verantwortungen „Product Owner“ und „Entwickler“, aber auch in den beiden Backlogs. Das Product-Backlog beschreibt das „Was“ und das Sprint-Backlog das „Wie“.
Die Chancen stehen gut, dass das „Was“ in deinem Team bereits gut sichtbar ist. Dein Team hat wahrscheinlich ein Product-Backlog. Gilt das Gleiche für die Qualität und somit für die Arbeit, die die Entwickler jeden Sprint leisten? Ist sie auch für jeden sichtbar?
Falls nicht, nutze das „Now, Next, Later“-Vorgehen in deiner nächsten Sprint-Retrospektive. Dadurch machst du die Definition of Done transparent. Ich habe die Anleitung formuliert, als gäbe es noch keine Definition of Done, da die Chancen gut stehen, dass auch bei vorhandener Definition of Done die wenigsten ihre Einträge wirklich kennen.
Hier das „Now, Next, Later“-Vorgehen für einen Workshop:
Schritt 1: Bitte die Mitglieder deines Scrum Teams (lade gerne auch Stakeholder dazu ein), ein Brainstorming durchzuführen. Was sollte alles Teil der Definition of Done sein, damit unsere Arbeit den höchsten Qualitätsstandards entspricht und die Arbeit am Inkrement vollständig abgeschlossen ist? Beim Brainstorming sind alle Vorschläge erlaubt.
Schritt 2: Nun lasse die Teammitglieder die Punkte identifizieren, die sie bereits tun oder jetzt tun könnten. Diese Punkte gruppierst du unter „Now“.
Schritt 3: Bei den restlichen Vorschlägen hilfst du dem Team zu entscheiden: Können wir mit diesem Vorschlag die aktuelle Definition of Done verbessern? Dann gruppiere den Punkt unter „Next“. Eine dieser Verbesserungen könnten wir direkt im nächsten Sprint umsetzen. Kostet euch die Umsetzung dieses Vorschlags viel Zeit oder Geld, dann ordnet ihn unter „Later“ ein. (Bevor diese Vorschläge umgesetzt werden, müssen sie erst zerkleinert werden.)
Mit dem „Now, Next, Later“-Vorgehen hast du die aktuell geltende Definition of Done sowie mögliche Verbesserungen sichtbar gemacht. Du hilfst deinem Team damit, das Produkt zu verstehen. Auch die Stakeholder verstehen, was die Entwicklung bedeutet. Zudem wird klar, welche Qualitätsansprüche gelten.
Damit machst du den Entwicklern ein Angebot, für die Qualität des Produkts Verantwortung zu übernehmen.
Tipp 3: Wechsle das Format für das Daily Scrum täglich ab
Was unterscheidet einen Statusbericht von einem Daily Scrum?
Als Scrum-Coach wurde ich vor einiger Zeit beauftragt, ein Unternehmen bei der Einführung von Scrum zu begleiten. Als ich zu dem Team kam, schien alles bereits eingespielt zu sein. Ein ehemaliger Projektleiter fungierte als Scrum Master und einer der Produktmanager des Unternehmens übernahm die Rolle des Product Owners. Nennen wir den Projektleiter ab jetzt Hugo. Das Einzige, worum ich gebeten wurde, war, mir das Daily Scrum anzusehen, da die Entwickler so passiv waren und sich nicht einbrachten.
Da ich neue Teams immer erst einmal beobachte, stellte ich mich beim Daily Scrum einfach zum Team dazu. Als das Daily Scrum begann, holte der Hugo sein Klemmbrett hervor. Er wollte sich etwaige Probleme notieren. Er fragte jeden Entwickler der Reihe nach ab. Er wollte wissen, was sie gestern getan hatten.
In diesem Moment verstand ich:
Den Entwicklern blieb keine andere Möglichkeit, als passiv zu sein. Wenn sie nicht an der Reihe waren, konnten sie sich nicht einbringen. Hugo ist dabei kein Vorwurf zu machen; er versuchte die Hindernisse zu identifizieren, welche die Entwickler von ihrer Arbeit abhielten.
Das Problem war das gewählte Format des Daily Scrums.
Es zwang Hugo und die Entwickler in eine Situation, in der sich niemand wirklich einbringen konnte. Es handelte sich um einen Statusbericht. Jeder Entwickler berichtete dem Scrum Master, was er gestern getan hatte. Die Entwickler mussten Rechenschaft über ihr Handeln ablegen. Für mich ist ein Statusbericht der Inbegriff von Zombie-Scrum.
Nach dem Daily Scrum gab ich dem Team einen Rat. Die Teammitglieder sollten unterschiedliche Formate für ihr Daily Scrum ausprobieren. Dann sollten sie entscheiden, welches ihnen am besten gefiel.
Ich schlug ihnen diese drei Varianten vor. Wenn du auch nach Wegen suchst, damit sich die Entwickler mehr einbringen können, dann probiere sie unbedingt aus.
Hier die Alternativen zu einem Statusbericht:
Variante 1: Die 3 Daily-Scrum-Fragen
- Was habe ich gestern getan, das dem Scrum Team geholfen hat, das Sprint-Ziel zu erreichen?
- Was werde ich heute erledigen, um dem Scrum Team beim Erreichen des Sprint-Ziels zu helfen?
- Sehe ich irgendein Hindernis, das mich oder das Scrum Team daran hindert, das Sprint-Ziel zu erreichen?
Diese Variante kann schnell zu einem Statusbericht abdriften, deshalb beachte: Der Scrum Master stellt nicht die Fragen. Es geht nicht um den persönlichen Fortschritt der Entwickler. Stattdessen geht es um den Fortschritt bei der Erreichung des Sprint-Ziels.
Variante 2: Team- oder Skalierungsfragen
- „Mit wem willst du heute an welchem Eintrag arbeiten, damit wir dem Sprint-Ziel näher kommen?“
- „Auf einer Skala von 1 bis 10, wobei 1 „wenig zuversichtlich“ und 10 „sehr zuversichtlich“ bedeutet: Wie zuversichtlich bist du, dass wir das Sprint-Ziel bis zum Ende des Sprints erreichen?“
Variante 3: „Walk-the-Board“-Methode
Statt Fragen steht jetzt das Scrum Board im Mittelpunkt:
- Die Entwickler beginnen damit, die Arbeiten zu besprechen, die sich in der „done“-Spalte des Scrum Boards befinden. Sie starten also auf der rechten Seite.
- Im nächsten Schritt besprechen sie die Arbeiten, die noch nicht fertig sind. Auf einem Scrum Board ist dies typischerweise die „doing“-Spalte.
- Und falls nötig, besprechen sie zum Schluss noch die Arbeiten, die sich noch in der „to do“-Spalte des Scrum Boards befinden.
Das Ziel dieses Gesprächs besteht darin, im Laufe des Tages möglichst viele Arbeiten zu erledigen. Wir wollen Aufgaben aus der „doing“-Spalte in die „done“-Spalte verschieben. So kommen wir dem Sprint-Ziel näher. Es geht also um Aufgaben, nicht um Personen.
Es gibt drei Varianten, die du deinem Team vorschlagen kannst. Die Teammitglieder sollen sie ausprobieren, um mehr Verantwortung im Sprint zu übernehmen. Falls du noch mehr Varianten kennenlernen möchtest, schaue dir dieses Video an. Dort stelle ich weitere Varianten vor.
Wie kann es im Kampf gegen Zombie-Scrum für dich weitergehen?
Was haben der „All Hands All Ears“-Workshop, das „Now, Next, Later“-Vorgehen und die drei Daily-Scrum-Formate gemeinsam?
Es handelt sich um Facilitation-Methoden.
Gute Fähigkeiten in Facilitation helfen dir, dein Team von Zombie-Scrum zu heilen. Wenn du neben dem „All Hands All Ears“-Workshop oder dem „Now, Next, Later“-Vorgehen auch „White Elephant“-Prinzipien oder die „Groan Zone“-Brille in deiner Arbeit als Facilitator nutzen willst, dann empfehle ich dir den Besuch des „Professional Scrum Facilitation“-Trainings.
Ich bin fest davon überzeugt, dass eine der ersten Fähigkeiten, die Scrum Master erlernen sollten, die Facilitation von Workshops und Scrum Events ist. Im Kern bedeutet Facilitation, die Erfolge für dein Team zu erleichtern. Es ermöglicht dir, dass die Mitglieder deines Scrum Teams Verantwortung übernehmen und sich kontinuierlich verbessern, ohne dass du sie bevormundest. Wie es häufig bei Scrum Mastern zu beobachten ist, die ihre Rolle nicht als Facilitator, sondern als Scrum-Lehrmeister sehen. Also jemand, der vorschreibt, wie es geht und was richtig und falsch ist.
(Unter uns: Dies ist ein schlechtes Mittel gegen Zombie-Scrum.)