3 Fehler von Scrum Mastern und wie man sie behebt

Ein Scrum Master zu sein, kann eine ganz schön schwierige Aufgabe sein.

Geben Sie einem Team zu viele Ratschläge und Hilfestellung, gewöhnt sich das Team bald daran, sich alles vom Scrum Master vorgeben zu lassen. Geben Sie dem Team jedoch zu wenig Hilfestellung, entwickelt es sich langsamer als es könnte. Lösen Sie einige Probleme für das Team und bald wird von Ihnen erwartet, jedes Problem zu lösen. Wenn Sie jedoch nicht die Probleme des Teams lösen, hören die Teammitglieder irgendwann sogar auf, ihrem Scrum Master von ihren Impediments und Problemen zu berichten.

Scrum Master bewegen sich auf einem schmalen Grat und es ist ein Leichtes, Fehler zu begehen. In diesem Artikel werden drei Fehler beschrieben, die Scrum Master häufig machen, und für jeden dieser Fehler wird dann ein kurzer Lösungsvorschlag geboten.

1) Arbeiten in den nächsten Sprint überschwappen lassen

Der erste Fehler ist meines Erachtens eine der schlimmsten Gewohnheiten, die ein Team entwickeln kann: Arbeiten von einem Sprint in den nächsten schwappen zu lassen.

Dies passiert, wenn ein Team nicht alle Product Backlog Items fertigstellt, die für einen Sprint geplant waren, und diese Arbeiten einfach mit in den nächsten Sprint nimmt.

Nicht, dass Sie mich falsch verstehen: Ab und zu wird es vorkommen, dass ein Team nicht mit allem fertig wird. Tatsächlich ist es sogar ein gutes Zeichen, wenn das manchmal passiert. Es bedeutet nämlich, dass das Team sich selbst einen strammen Plan vornimmt und sich nicht aus Angst, nicht alles schaffen zu können, zu wenig Arbeit für einen Sprint einplant.

Allerdings sollte ein Scrum Master es auch nicht als Kavaliersdelikt ansehen, wenn ein Team nicht mit den geplanten Arbeiten fertig wird, denn sonst werden Sprints zu künstlichen und bedeutungslosen Grenzen. Teams sollten einen leichten Druck verspüren, wenn es auf das Ende des Sprints zugeht. Ein Team sollte denken: „Ohh, der Sprint endet morgen. Ich muss heute echt fokussiert bleiben und fertig werden.”

Wenn das Überschwappen von Arbeit in den nächsten Sprint in Ihrem Team ein Problem darstellt, gibt es einige Dinge, die Sie dagegen tun können:

Als Erstes müssen Sie diese schlechte Angewohnheit loswerden. Ermutigen Sie die Teammitglieder, ihren nächsten Sprint so zu planen, dass sie definitiv alle Arbeiten schaffen. Dass heißt, dass sie es ruhig angehen lassen sollten und den nächsten Sprint eher mit etwas Vorsicht planen sollten. Wenn dann alles gut läuft, können mehr Arbeiten in den Sprint aufgenommen werden.

Außerdem können Sie versuchen, dafür zu sorgen, dass sich das Team ein kleines Bisschen schuldig fühlt, wenn nicht alles erledigt wird. Es geht nicht darum, dass sich jemand wirklich schlecht fühlen soll. Die Teammitglieder sollen nur so ein schlechtes Gewissen haben wie ich gerade. Ich versuche nämlich, nicht mehr so viele Softdrinks zu trinken. Ich mache auch schon Fortschritte und habe seit einer Woche keine mehr getrunken. Aber heute, während ich diesen Artikel schrieb, war mir irgendwie danach. Also habe ich mir einen Softdrink gegönnt. Ich fühle mich deswegen nicht schlecht, aber ich will morgen definitiv nicht noch einen trinken, damit ich nicht in alte Gewohnheiten zurück falle.

2) Durchführung der Daily Scrums

Ein zweiter Fehler, den ich häufig bei Scrum Mastern beobachte, ist, dass sie die Durchführung des Daily Scrums übernehmen. Natürlich sollte der Scrum Master an den Daily Scrums teilnehmen und auch selbst ein Update geben. Jedoch muss der Scrum Master nicht das Meeting leiten, um die Teammitglieder immer wieder aufzufordern, sich zu beteiligen usw.

Der Scrum Master sollte die Regeln und den Grund für das Daily Scrum erklären und die ersten zwei, drei Meetings leiten und die Leute dazu auffordern, sich zu beteiligen. Danach sollte er aber das Team selbst die Daily Scrums durchführen lassen.

Die Aktivitäten eines Daily Scrums sind nicht besonders schwierig. Es wird kein „Polizist” benötigt, der alles regelt, denn wenn der Scrum Master das Meeting auf diese Art und Weise leiten würde, würde sich die Diskussion zu sehr an den Scrum Master richten.

Ich beginne mit einem neuen Team gerne so, dass ich definitiv die ersten Meetings selbst moderiere. Dann sage ich irgendwann nur noch „Okay Leute, es ist Zeit anzufangen” und frage vielleicht noch, wer anfangen möchte. Aber bald höre ich auch damit auf.

Nach einigen Meetings fange ich dann damit an, offensichtlich auf meine Uhr zu schauen, wenn es an der Zeit ist, das Meeting zu starten. Wenn nötig, räuspere ich mich laut genug, damit alle verstehen, was los ist. Und dann stehe ich einfach nur still da, bis irgendjemand sagt: „Oh, ich glaube, wir sollten anfangen.” Nach ein paar Tagen, in denen ich auf die Uhr schaue und mich räuspere, gehe ich noch einen Schritt weiter und schaue nur noch auf die Uhr, wenn es Zeit ist, anzufangen. Und wieder nach ein paar Tagen höre ich sogar damit auf. Ich stehe einfach nur da und warte darauf, dass das Meeting beginnt.

Natürlich schweige ich nicht während des gesamten Meetings. Unter Umständen muss ich jemanden coachen, mehr ins Details zu gehen, oder ich unterbreche jemanden höflich und schlage vor, ob man sich nicht vielleicht nach dem Daily Scrum mit den Einzelheiten auseinandersetzen sollte.

Stellen Sie sich doch einfach einmal vor, ich (oder eine andere fremde Person) wäre bei Ihrem Daily dabei. In diesem Fall sollte man nicht alleine durchs Zuschauen herausfinden können, wer der Scrum Master im Team ist. Es wird sicherlich ab und zu vorkommen, dass der Scrum Master etwas sagt, dass nur ein Scrum Master sagen würde. Das sollte jedoch nicht ständig vorkommen.

3) Das Team auf ein Burnout zusteuern lassen

Ich bin kein besonders großer Fan der meisten Scrum-Begriffe, aber der Terminus Sprint ist besonders problematisch. Wenn ich beim Laufen sprinte, werde ich schnell müde und muss immer wieder Pausen einlegen. Das ist eine ziemlich schlechte Metapher für ein Team.

Ein Sprint endet und der nächste beginnt. Teams sollten nicht mit dem nächsten Sprint anfangen, während sie noch dabei sind, sich von dem letzten Sprint zu erholen. Vielmehr sollten Teams mit einer nachhaltigen Geschwindigkeit arbeiten, die durch Kent Beck als Sustainable Pace bekannt wurde.

Der dritte Fehler, den ich oft sehe, ist, dass Scrum Master es oft zulassen, dass ihre Teams diese nachhaltige Geschwindigkeit überschreiten und auf ein Burnout hinarbeiten. Ein guter Scrum Master sollte gut aufpassen und das Team ggf. vor einem Burnout schützen.

Viele Teams sind optimistisch eingestellt und dieser Optimismus überträgt sich auf die Menge der Arbeit, die sie sich für einen Sprint vornehmen. Scrum Master sollten auf der Hut sein und den Teams zur Vorsicht raten, wenn sie im Sprint Planning Gefahr laufen, mehr Commitments für einen Sprint einzugehen, als sie in bisherigen Sprints geschafft haben. Warum? Weil das Team, selbst wenn noch alle Arbeiten im Sprint fertiggestellt werden können, Gefahr läuft, den nächsten Sprint erschöpft und mit zu viel Optimismus bezüglich der Menge an Arbeit zu beginnen. An irgendeinem Punkt wird das Team keine nachhaltige Geschwindigkeit mehr einhalten können und „ausbrennen”. Eine gute Möglichkeit, ein Team vor dieser Situation zu schützen, ist, dem Team Freiräume zu schaffen, in denen sie sich selbst überlegen können, an was sie arbeiten wollen.

6 x 2 + 1

Dafür nutze ich gerne eine Methode, die ich „6 x 2 + 1” nenne. Das bezieht sich auf sechs zweiwöchige Sprints plus einen einwöchigen Sprint ganz zu Schluss. Die Teammitglieder können sich dann selbst aussuchen, an was sie in dem letzten Sprint arbeiten möchten. Einige Leute nutzen diese Zeit für ihre persönliche Weiterbildung (ein Buch lesen, Video-Training usw.). Andere nutzen die Zeit, um unschönen Code zu refaktorieren, den der Product Owner nicht priorisiert hat. Wieder andere Teammitglieder versuchen sich vielleicht an einem Experiment, das ihrer Meinung nach zu einem tollen neuen Feature führen könnte. All das kann sich das Team ganz allein überlegen.

Einen solchen Zyklus einzuführen, kann allerdings noch viel mehr Vorteile haben. Der Product Owner hat auf diese Weise zum Beispiel auch eine ganze Woche, ohne vom Team „gestört” zu werden. Und genau das ist oft das beste Verkaufsargument, um einen Product Owner mit ins Boot zu holen.

Dieser Zyklus kann auch für die gesamte Organisation von Vorteil sein, wenn man dort Commitments eingehen muss wie z.B. „Wir müssen dieses Feature in 3 Monaten geliefert haben!” Die 13. Woche der 6 x 2 + 1 Sprints kann auch für einen normalen Sprint genutzt werden, wenn das Team in Hinblick auf eine Deadline in Verzug geraten ist. Wenn das Team dann später die Deadline einhalten konnte, kann man ihnen immer noch einen einwöchigen Sprint zur freien Verfügung einräumen.

Lerne mehr über diese Punkte in unseren Trainings zum Certified ScrumMaster und werde innerhalb von drei Tagen fit in dieser agilen Rolle und lerne Verantwortung als Servant Leader zu tragen.