Eine kleine Geschichte: Jeden Tag um 9:15 Uhr…

…ist Daily Scrum. Es ist 9:18 Uhr und das Entwicklerteam werkelt im Teamraum an seinen Rechnern geschäftig vor sich hin. Plötzlich öffnet sich die Tür und der Product Owner stürmt hinein. Er wirft sein Sakko über den nächsten Stuhl, wünscht den Anwesenden einen guten Morgen und prustet: „Na, schauen wir mal, wie’s so lief“. Ihm folgt auf dem Fuße der Scrum Master, der sich sogleich neben dem Task Board positioniert, die stolzgeschwellte Brust hebt und verkündet, es könne nun losgehen.

Das Entwicklerteam erhebt sich zunächst verhalten von den Sitzen, blickt dann jedoch auf die motivierten Neuankömmlinge, um alsbald im perfekten Halbkreis am Board anzutreten.

Ganz links am Rand der Runde steht Hannes und lässt den Blick über das bunte Story Board schweifen. Der Verlauf des Burn Up Charts lässt ihn unvermittelt an die Temposchwelle denken, die er heute morgen mit deutlich zu hoher Geschwindigkeit mitgenommen hat. Jetzt jedoch spürt er den Ellenbogen des Nebenmannes, der ihn mit weit geöffneten Augen und einem leichten Nicken auffordernd ansieht. Er registriert die gesammelten Augenpaare auf seiner Person, den leicht dissoziierten Blick des Product Owners, räuspert sich und beginnt: „Äh, ja, natürlich… Gestern war ich dran an der 458, 460 und der 512. Oh, und die ist jetzt done!“. Darauf springt der Scrum Master pflichtbewusst vor das Board, hängt die Story stolz in die „Done“-Spalte, tauscht anschließend einen kurzen Blick mit dem Product Owner und manövriert sich wieder aus dem Blickfeld. Er ergänzt: „OK, und weiter?“

Fabian bemerkt die kollektive Aufmerksamkeit auf sich und entgegnet: „Bin weiterhin an der 388 dran!“, was der Scrum Master nach kurzer Pause mit einem „Alles klar“ quittiert.

So läuft der imaginäre Staffelstab einmal durch die Reihe der Entwickler. Als Letzter in der Runde ergänzt der Scrum Master noch: „Nun denn, vielen Dank. Jemand noch Probleme?“, und blickt auf die Liste der Impediments. Seit vorletzter Woche steht auf der leicht abgewetzt mit einem White Board Marker das Wort „Kaffeepads“. Die sind nämlich leer, nachdem die großzügigen Vorräte vom Projektbeginn aufgebraucht waren. Als Konsequenz ziehen sich seit letzter Woche die Kaffeetrinker ihren Wachmacher aus dem Automaten im Erdgeschoss. Jürgen hat wohl schon mal darüber nachgedacht, einfach welche im Internet zu bestellen, aber dann wusste er nicht genau, an wen die Rechnung gehen soll oder ob er das Geld sogar vorstrecken müsste…und hat sich doch lieber wieder einen einzelnen Kaffee aus dem Automaten gezogen.

Als sich niemand meldet, um noch was zu ergänzen, nickt der Scrum Master zufrieden, schaut auf seine Uhr, stellt mit Freude fest, 9:29 Uhr – wieder innerhalb der 15 Minuten Timebox geblieben – und schließt mit der Bemerkung: „Prima, dann mal weiter. Es sind noch drei Tage bis zum Sprintende!“ Nach einem kurzen Blick zum Product Owner ergreift dieser nochmal das Wort: „Danke, ich bin heute bis vier Uhr im Meeting, danach aber im Büro, wenn ihr Fragen habt“, worauf das Team pflichtbewusst nickt, der Product Owner sich sein Sakko greift und mit den Augen auf dem Smartphone aus dem Teamraum eilt. Hannes macht noch eine Bemerkung darüber, dass er nun endlich sein gesammeltes Kleingeld an den Automaten los werden kann – was der Scrum Master als Teetrinker mit einem „Ihr mit eurem Kaffee…“ quittiert –  und setzt sich zusammen mit den anderen wieder an seinen Platz.

Was war hier los?

Die kleine Geschichte von eben enthält eine Kombination von Antipattern im Daily Scrum. Teile davon kommen euch sicher bekannt vor:

Das Daily Scrum verkommt zum Statusbericht

Der Hauptgrund, ein Daily Scrum abzuhalten, ist die Abstimmung des Teams zu Beginn eines Tages. Hier besprechen die Entwickler, woran sie arbeiten werden – und das ist keineswegs ein sequentieller Monolog! Hier werden Teams fürs Pairing gebildet, sinnvolle Informationen ausgetauscht („Oh, das hatte ich letztens schon mal! Das ist ein Bug im JDK.“) und Impediments angesprochen.

Klar, als Daily-Teilnehmer sollte man nicht zu jedem Task einen Vortrag halten, aber stoisch herunterzubeten, welche Stories noch in Arbeit sind und welche nicht, ist KEIN Daily Scrum! Diese Information kann man auch ohne Tonspur am Taskboard ablesen.

Unterm Strich sollen bei jedem Beitrag eines Team-Mitglieds die drei Daily-Fragen beantwortet werden:

1. Was habe ich seit dem letzten Daily getan?
2. Was werde ich bis zum nächsten Daily tun?
3. Was behindert mich?

(Den Fokus dabei auf „Was habe ich geschafft?“ und „Was werde ich schaffen?“ zu legen ist keine schlechte Idee, fokussiert man sich dabei doch noch ein wenig mehr darauf, Aufgaben abzuschließen).

Das Meeting wird für den Product Owner veranstaltet

Wie gerade schon ausgeführt: das Daily Scrum ist für das Team!

Der Product Owner ist nicht der Hauptstakeholder dieser täglichen Runde. Für ihn ist es zwar nett, den Fortschritt innerhalb des Sprints mitzubekommen, aber was für ihn zählt, ist das Commitment des Teams zum gesamten Sprintinhalt zu Beginn des Sprints. Er nimmt stattdessen teil, um dem Team wichtige Informationen beizusteuern. Blickt zum Beispiel an einer Stelle die Erkenntnis durch, dass die Story doch nicht ganz so klar beschrieben ist wie gedacht, hat der PO hier die Chance, direkt auszuhelfen oder bietet an, sich alsbald mit der Thematik zu beschäftigen. Das spart den Entwicklern unter Umständen viel Zeit, in der sie nicht versuchen, sich das fehlende Akzeptanzkriterium logisch herzuleiten (was im Zweifel dann auch noch falsch ist, weil sie den vollständigen Kontext der Anforderung nicht kennen).

Dem Scrum Master ist der Rahmen des Meetings wichtiger als dessen Inhalt

Hauptkriterium wie für jedes Meeting ist, dass dadurch ein Mehrwert entsteht. Timeboxes sind ein wichtiger Faktor in Scrum und ihre Überschreitung ist ein Indikator dafür, dass wahrscheinlich der Fokus verloren wurde. Gleichzeitig ist eine Länge von unter 15 Minuten beim Daily aber keineswegs ein Garant dafür, dass es sich um ein gelungenes Meeting handelt. Die meisten Anfängerteams werden diese Viertelstunde am Anfang hoffnungslos reißen, weil sie sich in Detaildiskussionen verstricken. Eine Besinnung auf die Timebox des Meetings hilft dann häufig zurück zum Fokus aufs Wesentliche. Ich habe auf der anderen Seite schon mit einem Team gearbeitet, das über einige Dutzend Sprints keinen Mehrwert darin sah, seine tendenziell 30-minütigen Daily Scrums künstlich zu verkürzen (die Länge des Meetings wurde in Retrospektiven mehrfach thematisiert). Hier wurde mit verschiedenen Alternativen experimentiert:

• „Hartes Unterbrechen“ durch den Scrum Master, denn so wichtig könne das Thema nun auch wieder nicht sein. Dies führte nicht zu besserem Fokus, sondern lediglich zu Grundsatzdiskussionen über die Wichtigkeit einzelner Informationen.
• Themen kurz ansprechen und wenn sich zeigt, dass dort Diskussionsbedarf besteht, wird es ans Whiteboard geschrieben und anschließend in kleinerer Runde besprochen. Diese Maßnahme führte dazu, dass sich zu anschließender Diskussion häufig lediglich Scrum Master und Product Owner entfernten und das Entwicklerteam geschlossen stehenblieb. Trotzdem war das der Weg, den wir bis zum Schluss gegangen sind, denn die Trennung der Diskussionen in offiziellen Daily-Part und speziellen After-Daily-Part zeigt an, dass anschließend nicht mehr jeder teilnehmen muss. Wenn anschließend alle stehen bleiben ist das OK. Es sollte nur niemand stehen bleiben müssen, obwohl er nichts Sinnvolles beizutragen oder zu erfahren hat. Scrum ist lean und „grundlos mitmachen“ ist auch Verschwendung.

Weiterhin ist es nicht der Scrum Master, der definiert, wann zu einem Thema „alles klar“ ist. Die Teammitglieder schließen ihre Redebeiträge selbst. Genausowenig aktualisiert der Scrum Master das Task Board. Gerade, wenn es darum geht, Stories auf „Done“ zu schieben, sollte dieses kleine Glücksgefühl dem Entwickler zuteil werden, der die Anforderung abgeschlossen hat.

Das Lösen von Impediments obliegt allein der Scrum Master-Rolle

Hier wurde als Beispiel genommen, dass der Kaffee zur Neige geht. Der Scrum Master sah es nicht als seine Aufgabe an, für Nachschub zu sorgen. Und das ist genau genommen auch nicht zwingend der Fall. Allerdings ist er in der Verantwortung dafür, dass das Impediment aus dem Weg geräumt wird. Er sollte also wenigstens dafür sorgen, dass sich jemand findet, der neuen Kaffee besorgt.

Und sollte der Scrum Master ein Impediment mal nicht als solches betrachten, helft ihm auf die Sprünge und verleiht dem Nachdruck! Hier wollte ein Teammitglied ja bereits in die Bresche springen und welchen besorgen, ließ es dann aber aus Bequemlichkeit doch bleiben. Auch oder grade im Daily Scrum sollten Fragestellungen für die Beseitigung von Impediments besprochen werden (auch die banale Frage, wie der Kaffee abgerechnet wird…).

Daher:

Betrachtet das Daily Scrum pragmatisch und besinnt euch auf seine Grundsätze, denn das Daily Scrum ist kein Selbstzweck. Das Daily darf nicht zum Statusbericht verkommen, sondern ist ein wichtiger Grundpfeiler der operativen Strategie, die täglich abgestimmt wird. Die gewissenhafte Beantwortung der drei Fragen ist zwingender Bestandteil jeden Beitrags eines Team-Mitglieds.