Ein zentrales Element jedes Scrum-Teams ist das Daily Scrum, bei dem sich die Entwickler täglich zur selben Zeit für 15 Minuten treffen, um Fortschritte in Bezug auf das Sprintziel zu diskutieren. Bei Bedarf, insbesondere wenn das Erreichen des Sprintziels gefährdet scheint, ergreifen sie Maßnahmen wie die Anpassung des Sprint Backlogs.
Dailys wurden zwar schon lange vor Scrum eingesetzt, doch ihre wahre Verbreitung fanden sie erst mit dem Siegeszug von Scrum. Jeff Sutherland, einer der Begründer von Scrum, betont die Bedeutung des Daily Meetings: Es fördert den Teamgeist, unterstützt das schnelle Beseitigen von Hindernissen und steigert sowohl Produktivität als auch Commitment des Teams.
So habe ich es auch schon selbst in Scrum-Projekten erlebt, an denen ich beteiligt war. Es gibt allerdings auch weniger inspirierende Beispiele: langweilige Dailys, in denen die Entwickler dem Product Owner und/oder Scrum Master lustlos ihren Fortschritt berichten, während die anderen Teammitglieder sich langweilen und im Remote-Setup vermutlich oft einfach an ihren User Stories weiterarbeiten. Es mag einfach erscheinen, in solchen Projekten einfach auf die Dailys zu verzichten.
Ich habe einen anderen Ansatz gewählt. Zunächst habe ich zusammen mit Kolleginnen und Kollegen bei doubleSlash reflektiert, ob sie ähnliche Erfahrungen gemacht haben und welche Ursachen dahinterstecken könnten. Unsere Erkenntnis: Die beschriebene Situation spiegelt lediglich Symptome eines tieferliegenden Problems wider, das maßgeblich auf zwei Faktoren beruht: Verantwortlichkeit und Entscheidungshoheit.
Unterschiedliche Zusammenarbeitsmodelle
Einige von uns werden sie noch in (mehr oder weniger guter) Erinnerung haben – die Wasserfall-Projekte. Diese Projekte auch durch ein bestimmtes Zusammenarbeitsmodell geprägt. Dieses Modell war charakterisiert dadurch, dass jedes Teammitglied nur für seine eigenen Themen verantwortlich war – heute würden wir von User Stories und Tasks sprechen. Ein Projektleiter, unterstützt von Teilprojektleitern, trug die Gesamtverantwortung für das Projekt. Die Teammitglieder berichteten an den Projektleiter.
Mit der Einführung von Scrum änderte sich auch die Zuordnung von Verantwortlichkeiten und Entscheidungshoheit. Im Scrum liegt die Erreichung des Sprintziels in der Verantwortung des Entwicklerteams – daraus leitet sich auch der Gedanke ab, dass ein Projektleiter in agilen Projekten nicht mehr notwendig ist. Das bedeutet, jeder im Team muss sich für den Fortschritt der anderen Teammitglieder interessieren, da alle das Gesamtergebnis gemeinschaftlich verantworten. Sollte ein Teammitglied auf Probleme stoßen, kann das Team entscheiden, gemeinsam an einer Lösung zu arbeiten, bis das Problem behoben ist. In einer solchen Konstellation von Verantwortung und Entscheidungshoheit macht ein Daily wieder deutlich mehr Sinn. Es gibt dem gesamten Team nämlich die Möglichkeit, das weitere Vorgehen gemeinsam zu besprechen.
Wenn die Theorie auf die Praxis trifft
Leider habe ich dieses Zusammenarbeitsmodell in nur sehr wenigen Scrum-Teams implementiert vorgefunden. Häufig wurde Scrum nur als Prozessschablone eingeführt, mit Übernahme der Terminologie, doch die Beteiligten hielten an dem alten Modell von Verantwortlichkeiten und Entscheidungsbefugnissen fest. In der Praxis zeigt sich dies, indem der Projektleiter zum Product Owner und die Teilprojektleiter zu Sub-Product Ownern umbenannt werden. Alle Teammitglieder berichten an den Product Owner (bzw. Sub Product Owner), wie sie es früher beim Projektleiter (bzw. Teilprojektleiter) taten. Und die Dailys laufen so ab, wie zuvor beschrieben.
Wieso hält sich das klassische Zusammenarbeitsmodell so hartnäckig? Die Gründe sind sicher vielfältig. Ich möchte hier einige herausgreifen und anschließend Lösungsansätze dazu vorschlagen. Grundsätzlich ist das hierarchische Modell tief im Menschen verankert – es hat der Menschheit über Jahrtausende hinweg gedient und sollte nicht pauschal als negativ bewertet werden. Wie verhält es sich nun in vielen Scrum Projekten:
Oftmals ist es für Entwickler, Product Owner, Scrum Master und das Management nicht ersichtlich, dass das Verantwortlichkeits- und Entscheidungsmodell in Scrum sich vom klassischen Modell unterscheidet, trotz der klaren Darlegungen im Scrum Guide. Manche Developer ziehen es vor, diese Art der Verantwortung nicht zu übernehmen und konzentrieren sich lieber aufs Coden oder Designen, während sie die Verantwortung für Scope und Quality ihrer Stories anderen überlassen. In Bezug auf Time und Budget wird die Verantwortung oft beim Product Owner oder gelegentlich auch dem Scrum Master gesehen. Ein Grund hierfür kann auch in einem gelegentlich zu beobachtenden Verhalten von POs, Scrum Mastern oder des Managements sein: die Developer sollen zwar die Verantwortung tragen, wenn etwas schiefgeht, bekommen aber nur eingeschränkte Entscheidungshoheit zugebilligt: Schätzungen von Stories werden gedrückt und Stories werden unter Druck in Sprints aufgenommen.
Einige Product Owner und Scrum Master sind nicht bereit, Macht abzugeben. Sie bevorzugen es, Kontrolle auszuüben und direktes Reporting auf Mikromanagement-Ebene zu erhalten. Dies kann an einem Machtanspruch liegen, an fehlendem Vertrauen oder einfach an der persönlichen Neigung.
Lösungsansätze
Ich bin in solchen Situationen wie im Folgenden beschrieben vorgegangen. In einem ersten Schritt habe ich mit dem Team und ganz wichtig darüber hinaus viel expliziter über Verantwortlichkeiten und Entscheidungshoheiten in agilen Projekten gesprochen und beschrieben, was dies jeweils für die Rollen bedeutet. Dabei hat es geholfen auch explizit die Unterschiede zwischen dem klassischen Zusammenarbeitsmodell und dem Model in agilen Projekten darzustellen. Der zweite Schritt war, dieses Thema besonders in den Retrospektiven immer wieder anzusprechen und mit dem Team zu diskutieren, ob bestimmte Probleme hätten vermieden werden können, wenn Verantwortlichkeiten und Entscheidungshoheiten anders verteilt gewesen wären. Diese Maßnahmen zeigten nach und nach Wirkung und resultierten in zufriedeneren Teams und Kunden.
Wie so oft gibt es kein allgemein gültiges richtiges oder falsches Vorgehen. Ist einmal verstanden, wie der Scrum Guide die Vorgehensweise vorsieht, lässt sich die Methodik situativ anpassen. Dies sollte jedoch bewusst und nicht zufällig erfolgen, um suboptimale Ergebnisse zu vermeiden. Es ist entscheidend, dass Verantwortlichkeiten und Entscheidungshoheiten immer zusammenpassen; andernfalls droht Frustration. Nicht jeder Entwickler kann oder möchte denselben Umfang an Verantwortung übernehmen. Dies können die Entwickler im Team untereinander abstimmen. Beispielsweise könnten Teammitglieder mit mehr Erfahrung auch mehr Verantwortung übernehmen und ihre weniger erfahrenen Kolleginnen und Kollegen nach und nach dahin entwickeln, dass auch diese mehr Verantwortung übernehmen können (und dadurch häufig auch wollen). Es ist zudem wichtig, dies aktiv zu leben, zu fördern und nicht zuletzt auch einzufordern.
Die Rolle des Scrum Masters
Die Förderung all dessen ist eine wesentliche Verantwortung des Scrum Masters, was über die Rolle eines Teamsekretariats hinausgeht – eine Rolle, in die Scrum Master häufig gedrängt werden. Der Erfolg eines Scrum Masters hängt auch von der Veränderungsbereitschaft der anderen Teammitglieder und der Unterstützung durch das Management ab. Die Veränderung muss nicht über Nacht erfolgen; im Sinne des Kaizen-Prinzips geht es darum, sich kontinuierlich zu verbessern. Die Retrospektive bietet dem Team die Möglichkeit, über den aktuellen Stand von Verantwortlichkeit und Entscheidungshoheit zu reflektieren. Wenn das Team diesen Weg erfolgreich geht, werden die Dailys wieder zu einem spannenden und produktiven Austausch in einem motivierten Team.
Unsere Einschätzung
Dailys in der Scrum-Praxis offenbaren oft ein tieferliegendes Problem: Unklarheit in Bezug auf die Verteilung von Verantwortlichkeit und Entscheidungshoheit oder ein Mangel an Übernahme von Verantwortung, beziehungsweise Übergabe an Entscheidungshoheit. Das äußert sich in lustloser Teilnahme an Scrum Dailys. Die Transformation zu echter agiler Arbeitsweise erfordert eine klare Kommunikation und Anpassung der Verantwortlichkeiten und Entscheidungshoheit. Durch gezielte Anpassungen und die aktive Rolle des Scrum Masters kann das Daily Scrum zu einem dynamischen und effektiven Element der Teamarbeit werden, das echtes Engagement und kontinuierliche Verbesserungen fördert.
