Was macht einen guten Scrum Master aus? Ein guter Scrum Master hat natürlich den Scrum Guide gelesen, eine Schulung besucht, eine Prüfung abgelegt und so weiter. Aber das ist noch nicht alles, es ist erst der Anfang. Sie werden schnell feststellen, dass es in der Praxis noch viele Fähigkeiten braucht, um ein Scrum Team richtig zu leiten und zu coachen. Wir haben eine Reihe von häufigen Fallstricken für Scrum Master aufgelistet. Nutzen Sie sie zu Ihrem Vorteil. Vielleicht wissen Sie mehr, lassen Sie es uns wissen.
Fallstrick 1: Der Scrum Master dirigiert das Team
Eine der Rollen des Scrum Masters ist es ein Prozessmoderator zu sein, aber es stellt sich heraus, dass es nicht so einfach ist diese Rolle sauber zu erfüllen. Was sehen wir oft? Ein Scrum Event wie das Sprint Planning oder Daily Scrum, bei dem der Scrum Master viel redet und das Team auf den Scrum Master schaut. Der Scrum Master führt, anstatt zu leiten. Der Scrum Master verschiebt die Post-its, der Scrum Master verteilt Aufgaben, schreibt neue Aufgaben auf und fügt sie hinzu… und genau das ist nicht das, was ein Scrum Master tun sollte.
Was dann? Vor allem sollten die Fragen so gestellt werden, dass das Team selbst beginnt mit dem Vorstand zusammenzuarbeiten. „Sind alle Aufgaben, die erledigt werden, auch wirklich in done?“, „Nein? Dann kleben Sie bitte den Zettel in die rechte Spalte.“ „Welche Aufgaben wollen Sie heute erledigen?“ „Ich sehe einige Aufgaben, die heute erledigt werden müssen, wollen Sie gemeinsam entscheiden, wer was tun wird?“
Die Idee von Scrum ist, dass sich die Teams selbst organisieren. (Scrum Guide: „Coaching des Teams im Selbstmanagement“). Der Scrum Master leitet diesen Prozess und wird natürlich bei einem neuen Team etwas mehr steuern als bei einem fortgeschrittenen Team. Eine Fähigkeit, die Scrum Mastern wirklich hilft, ist: Fragen stellen. Ohne die Antworten selbst auszufüllen. Seien Sie also ab und zu ruhig, damit das Team Antworten findet und sie selbst aufgreifen kann.
Fallstrick 2: Der Scrum Master löst alles
Während eines Events wie dem Daily Scrum werden wahrscheinlich auch Hindernisse (Impediments) auftauchen. Im Scrum Guide wird die Rolle des Scrum Masters wie folgt beschrieben: “causing the removal of impediments”. Ein Fehler, den Scrum Master begehen, besteht darin, dass sie, sobald ein Hindernis auftaucht, sofort anfangen sich Lösungen auszudenken. Das ist zwar gut gemeint, aber wenig effektiv wenn man ein Team dazu bringen will sich selbst zu organisieren. Außerdem verfügt das Team über eine Menge Wissen. Der Tipp ist daher, die Diskussion mehr zu lenken: „Wir haben Hindernis X identifiziert, wissen wir, wie wir es lösen können?“ könnte eine Frage sein. Der Scrum Master ist derjenige der dafür sorgt, dass das Hindernis gelöst wird, er weist den Weg zur Lösung, aber er muss das keineswegs alleine tun. Nutzen Sie das Wissen des Teams.
Fallstrick 3: Der Scrum Master übernimmt auch die Rolle des Product Owners
Während eines Sprint Planning oder einer Sprint Review ist die Versuchung für den Scrum Master groß, den Platz des Product Owners zu sehr einzunehmen. Die Kunst besteht darin, ein Prozessmoderator zu bleiben und dem Product Owner in den richtigen Momenten das Wort zu erteilen. Schließlich ist der Scrum Master nicht für den Inhalt, sondern für das „Was“ verantwortlich. Das liegt in der Hand des Product Owners und der Entwickler. Vor allem für jemanden, der viel Wissen über den Inhalt hat, ist das eine Herausforderung. Aber bleiben Sie Prozessbegleiter! Stellen Sie sicher, dass der Product Owner und die Entwickler miteinander reden. Erteilen Sie dem Product Owner ausdrücklich das Wort. „Gute Frage, Katrin. Product Owner, können Sie das beantworten?“.
Bei der Festlegung von Prioritäten besteht die Falle, in die Scrum Master manchmal tappen, darin, dass sie eine Meinung dazu haben. Dann höre ich einen Scrum Master etwas sagen wie: „Ich schlage vor, dass Sie zuerst dies und dann das angehen“. Das ist natürlich etwas, was der Product Owner sagen sollte. Stellen Sie eine Frage: „Haben Sie sich schon entschieden, was Sie zuerst tun werden? Was brauchen Sie noch, um das entscheiden zu können?“
Wenn Sie die Sprint Review leiten, lautet der Tipp: Begrüßen Sie alle, nennen Sie kurz den Zweck dieses Treffens und sagen Sie dann: „Ich erteile nun dem Product Owner und dem Team das Wort, um zu berichten, wie der Sprint gelaufen ist, und um zu demonstrieren, was geliefert wurde“. Dazwischen sorgen Sie dafür, dass die Teilnehmer abwechselnd zu Wort kommen, sich gegenseitig ausreden lassen und der Stakeholder alle seine Fragen stellen und Feedback geben kann. Sie achten auf (nonverbale) Signale, die Sie möglicherweise aussenden (ich sehe, dass Sie die Stirn runzeln, Peter, haben Sie vielleicht noch eine Frage oder ein Anliegen?), und schließlich schließen Sie die Review ab. Auch hier gilt: Sie sind für den Prozess verantwortlich, aber die Inhalte und Prioritäten werden dem Product Owner und den Entwicklern überlassen.
Fallstrick 4: Retrospektiven, die zu kurz sind (oder gar nicht stattfinden)
Ein weiterer Fallstrick für den Scrum Master ist, dass ihm zu wenig Zeit zur Verfügung steht. Das Team verfällt in eine flüchtige Runde von „was ist gut gelaufen, was kann verbessert werden“ und das ist das Ende der Retro. Schade, denn die Retro ist auch der Moment, um das Team zu stärken. Der Scrum Master kann spielerische Methoden anwenden, die es dem Team ermöglichen sich auf eine andere Art und Weise kennen zu lernen. Es ist erwiesen, dass Teams besser zusammenarbeiten wenn sich die einzelnen Mitglieder besser kennen lernen. Stellen Sie eine verrückte Frage wie „Was war früher Ihr Lieblingsspielzeug“ oder „Wer würden Sie gerne einmal sein“. Oder spielen Sie ein gutes Spiel miteinander. Dieser Teil der Retrospektive wird auch als „Vertrauensbildung“ bezeichnet. Ein besseres gegenseitiges Kennenlernen ist eine gute Grundlage für Vertrauen und je mehr Vertrauen in einem Team herrscht, desto einfacher ist es zusammenzuarbeiten und Probleme gemeinsam zu lösen.
Sie müssen sich also wirklich etwas Zeit füreinander nehmen. Sie werden diese Zeit in einem effektiveren Team zurückgewinnen.
Es gibt auch Teams, die überhaupt keine Retro durchführen. Manchmal höre ich Leute sagen, dass Retro nicht wirklich notwendig ist. Nun, dieses Event wäre nicht Teil von Scrum gewesen, wenn es nicht notwendig wäre. Die Retro ist in der Tat wichtig, um den agilen Grundsatz „regelmäßig darüber nachdenken, wie die Zusammenarbeit verbessert werden kann“ zu konkretisieren. Lassen Sie sich als Scrum Master also nicht dazu verleiten, die Retro schnell zu erledigen oder sie ganz auszulassen. Sorgen Sie dafür, dass die Retro stattfindet und dass das Team merkt wie wichtig und schön es ist, eine zu haben.
