Was haben ein Archäologe und ein Scrum Master gemeinsam?
Ein Archäologe erforscht Überreste, um die Geschichte unserer Kultur zu verstehen.
Ein Scrum Master ergründet Prozesse, um die Hindernisse in der Zusammenarbeit zu finden.
Nicht so unterschiedlich, oder?
Archäologen geben sich nicht damit zufrieden, wie die Dinge an der Oberfläche scheinen. Sie graben tiefer. Behutsam nutzen sie Pinsel und Kelle, um die Funde nicht zu beschädigen. Sie wollen freilegen, ohne zu zerstören.
Was können wir als Scrum Master für Sprint Retrospektiven daraus lernen?
Wir sollten uns mit Retro-Formaten wie „Start, Stopp und Fortsetzen“ nicht begnügen. Sie kratzen nur an der Oberfläche. Wollen wir die wirklichen Hindernisse für unser Team finden, dann müssen wir tiefer graben. Gleichzeitig müssen wir sehr behutsam vorgehen, um kein Vertrauen zu zerstören.
Ähnlich wie Archäologen mit ihrem Werkzeug Schicht für Schicht freilegen, kannst du dafür als Scrum Master die folgenden drei Methoden nutzen. Beginnen wir mit der ersten:
Methode 1: Die „5 Warum“-Methode
Diese Methode hilft, die Ursachen eines Problems zu ergründen.
Die „5 Warum“-Methode wurde ursprünglich im Rahmen des Toyota-Produktionssystems entwickelt. Ihr Ziel ist es, die Wurzelursache eines Problems zu finden, indem wiederholt nach dem Warum gefragt wird.
Die 5 Schritte im Detail:
- Problem festhalten: Beginne damit, ein spezifisches Problem, das untersucht werden soll, genau zu definieren und zu beschreiben.
- Erste Warum-Frage stellen: Stelle die Frage: „Warum ist dieses Problem aufgetreten?“, und notiere die Antwort. Diese erste Antwort führt oft zu einer offensichtlicheren oder oberflächlicheren Ursache des Problems.
- Weitere Warum-Fragen stellen: Auf die erste Antwort folgen weitere Warum-Fragen. Jede Antwort wird mit einem weiteren „Warum?“ verfolgt, um tiefer in die Ursachenkette einzudringen.
- Wiederhole dies bis zur Wurzelursache: Dieser Prozess wird fortgesetzt, bis die Wurzelursache des Problems erreicht wird. Häufig geschieht das bereits nach fünfmaligem Fragen, daher der Name der Methode. Manchmal kann es jedoch mehr Fragen erfordern. Daumenregel: Wiederhole die Frage so lange, bis sich die Antworten wiederholen. Dann bist du an der Wurzel des Problems angekommen.
- Lösungen entwickeln: Sobald die Wurzelursache gefunden ist, können Maßnahmen zur Lösung erarbeitet werden. Dabei wird nun das grundlegende Problem adressiert und es werden nicht nur seine Symptome behandelt.
Lass uns die „5 Warum“-Methode an einem Beispiel betrachten.
Nehmen wir dazu an, dass in der „Start“-Spalte der Retrospektive die folgende Aussage steht: „Alle geplanten User Stories im Sprint abschließen“. Das Team konnte also nur sehr wenige der geplanten User Stories, die es sich vorgenommen hatte, im Sprint abschließen. Die Ursachenanalyse mit den „5 Warum“-Fragen könnte dann so aussehen:
- Warum konnten nicht alle geplanten User Stories abgeschlossen werden? Weil das Team den Arbeitsaufwand der User Stories unterschätzt hat.
- Warum haben die Entwickler den Arbeitsaufwand der User Stories unterschätzt? Weil ihnen die Erfahrung bei der Umsetzung dieser Features fehlte.
- Warum fehlte ihnen die Erfahrung bei der Umsetzung dieser Features? Weil drei erfahrene Entwickler letzten Monat das Team verlassen haben und die beiden neuen Mitglieder im Team frisch von der Universität kommen und noch keine Erfahrung mit unserer Software haben.
- Warum haben die neuen Teammitglieder keine Erfahrung mit unserer Software? Weil sie neu im Team sind und frisch von der Universität kommen.
Nach viermaligem „Warum“ sind wir am Ursprung des Problems angekommen.
Methode 2: Das Fischgräten-Diagramm
Das Fischgräten-Diagramm visualisiert die Ursachen eines Problems.
Die „5 Warum“-Methode sucht linear nach einer einzelnen Ursache. Im Gegensatz dazu ermöglicht das Ursache-Wirkungs-Diagramm eine umfassende Suche. Es fokussiert auf die vielfältigen Ursachen eines bestimmten Problems und ist vergleichbar mit dem Aussehen von Fischgräten.
So erstellst du ein Fischgräten-Diagramm:
- Problem klar definieren: Beginne damit, das Problem klar zu definieren, das an der Spitze des Diagramms dargestellt wird. Dieses Problem wird als der „Kopf des Fisches“ notiert.
- Hauptursachen identifizieren: Bestimme als Nächstes die Hauptursachen, die zu diesem Problem beigetragen haben. Diese Hauptursachen werden als die großen „Gräten“ dargestellt, die vom Fischkörper (dem Hauptproblem) abzweigen. Denke hierbei an Situationen, Prozesse, Menschen, Materialien und die Umwelt.
- Detaillierte Ursachen erfassen: Für jede Hauptursache identifizierst du nun spezifischere, untergeordnete Ursachen. Diese werden als kleinere Linien dargestellt und zweigen von den Hauptgräten ab.
- Diskussion: Diskutiere jede potenzielle Ursache und wie sie das Hauptproblem beeinflusst. Dieser Schritt kann durch Daten, Forschung oder Brainstorming unterstützt werden.
- Lösungen entwickeln: Entwickle, nachdem alle relevanten Ursachen identifiziert und analysiert wurden, Lösungen oder Maßnahmen, um die identifizierten Probleme anzugehen.
Lass uns das Fischgräten-Diagramm auch mit dem gleichen Beispiel visualisieren. Nach jeder Hauptursache folgen als Unterpunkte die Ursachen.
Teamfaktoren
- Unerfahrenheit: Mangel an Erfahrung bei der Umsetzung von Features für dieses Produkt.
- Überschätzung der Kapazität im Sprint: Falsche Einschätzung der Fähigkeiten während eines Sprints.
- Fehlende Fähigkeiten: Das Team konnte die neuen Teammitglieder nicht schnell genug einarbeiten.
Prozessfaktoren
- Ineffektive Sprintplanung: Die Verfügbarkeiten der Teammitglieder wurden aufgrund der Feiertage nicht richtig berücksichtigt.
- Chaotische Sprintplanung: Der Scrum Master konnte das Sprint Planning aufgrund von Krankheit nicht moderieren und es fehlte an einer klaren Agenda.
- Schlechte Schätzungen: Im Product Backlog Refinement wurde zu wenig Zeit für die Schätzungen aufgewendet, was dazu führte, dass die Anforderungen in den User Stories nicht ausreichend verstanden wurden und dadurch die erforderliche Zeit unterschätzt wurde.
Externe Faktoren
- Mehrere Anfragen vom Support: Einzelne Teammitglieder mussten stundenlang den Support bei der Lösung schwieriger Fälle unterstützen.
- Technische Schwierigkeiten: Probleme im Produktivsystem, die sofort behoben werden mussten.
Mit der „5 Warum“-Methode und dem Fischgräten-Diagramm kannst du deinem Team helfen, die Ursachen eines Problems umfassend zu verstehen. Die nächste Methode wird dir dabei helfen, potenzielle Schwachstellen in Lösungen aufzudecken.
Methode 3: Pre-Mortem
Analyse von Schwachstellen in Lösungen durch Pre-Mortem.
Diese Methode dient dazu, potenzielle Probleme und Schwachstellen in einer Lösung zu finden, bevor sie tatsächlich auftreten.
Pre-Mortem funktioniert so:
- Visualisierung: Zunächst wird die Lösung vorgestellt, die umgesetzt werden soll.
- Annahme des Scheiterns: Nun wird das Team aufgefordert, sich vorzustellen, dass die Lösung gescheitert ist. Es geht nicht darum, ob die Lösung funktioniert. Wir nehmen an, dass sie bereits gescheitert ist.
- Ursachen für das Scheitern identifizieren: Jedes Teammitglied überlegt individuell und schreibt die Gründe auf, warum es glaubt, dass die Lösung nicht funktioniert hat. Dabei sollte das Team kreativ sein und auch unwahrscheinliche Szenarien berücksichtigen.
- Diskussion und Analyse: Die Gründe für das potenzielle Scheitern werden dann im Team diskutiert. Dies ermöglicht es, unterschiedliche Perspektiven einzunehmen und mögliche Schwachstellen in der Lösung zu identifizieren.
- Entwicklung von Gegenmaßnahmen: Auf Basis der identifizierten potenziellen Schwachstellen der Lösung kann das Team nun Strategien entwickeln, um diese zu vermeiden.
Nehmen wir zum Schluss an, das Team entscheidet sich für die Lösung „Mehr Zeit für die Einarbeitung der neuen Teammitglieder im nächsten Sprint verwenden“, um das Problem „Alle geplanten User Stories im Sprint auch abschließen“ anzugehen. Dann können wir diesen Vorschlag mit einem Pre-Mortem auf Schwachstellen analysieren.
Nehmen wir dazu an, dass die zusätzliche Zeit für die Einarbeitung der neuen Teammitglieder nicht geholfen hat und im nächsten Sprint werden wieder fast keine User Stories abgeschlossen.
Was könnten dann die Ursachen dafür sein?
- Tom, der mit den neuen Teammitgliedern im Pair-Programming einzelne Stories umsetzen wollte, wurde krank.
- Es kommt während des Sprints oft zu Störungen durch Supportaufgaben. Dadurch wird die Arbeit häufig unterbrochen. Zudem sind die neuen Mitglieder größtenteils auf sich allein gestellt.
- Der Scrum Master moderiert das Sprint Planning nicht und deshalb wird nicht diskutiert, ob die User Stories so gut verstanden wurden, dass sie wirklich vom Team umgesetzt werden können.
Nun einige Beispiele von Gegenmaßnahmen:
- Im Sprint Planning einen Plan erstellen, wer mit wem welche User Stories im Pair-Programming umsetzen kann. Wichtig: mindestens drei Entwickler pro User Story.
- Weniger User Stories in den Sprint Backlog aufnehmen, damit noch Kapazitäten für ungeplante Arbeiten und Supportanfragen frei bleiben.
- Vorab den Scrum Master eines anderen Teams fragen, ob er im Notfall das Sprint Planning moderieren kann.
- Erstmal nur auf die Arbeit am Sprint-Ziel fokussieren und eine User Story abschließen, bevor weitere begonnen werden.
Diese Gegenmaßnahmen können dann die Verbesserung der Retrospektive für den nächsten Sprint darstellen.
Am 22. November 1922 war es so weit:
„Ich sehe wunderbare Dinge.“
Mit diesem Ausspruch sollte Howard Carter in die Geschichte der Archäologie eingehen. Nach acht Jahren gezielter Suche hatte er als Erster die Grabkammer des Pharaos Tutanchamun betreten.
Nutzt du die Archäologie-Methoden in deinen Retrospektiven, wird es dir ähnlich ergehen. Nein, nicht, dass es acht Jahre dauert, bis dein Team eine Lösung findet. Sondern, dass du wunderbare Dinge finden wirst. Ursachen für Probleme, die du an der Oberfläche einer „Start, Stopp und Fortsetzen“-Retrospektive niemals erwartet hättest. Dein behutsames, aber beständiges Freilegen offenbart die wirklichen Hindernisse der Teamarbeit.
Viel Spaß beim Ausgraben!