Das Daily muss heute leider ausfallen

Fast alle Unternehmen setzen auf das Daily als Meetingformat. Und fast alle Dailys sind eine Katastrophe: Langweilig, ineffizient und überflüssig. Warum?

In Pocket speichern vorlesen Druckansicht 408 Kommentare lesen
Gruppe von Menschen aus verschiedenen Ländern, die gemeinsam in einem Coworking-Space arbeiten.

(Bild: GaudiLab/Shutterstock.com)

Lesezeit: 14 Min.
Von
  • Golo Roden
Inhaltsverzeichnis

Es gibt eine Beobachtung, die mir immer wieder auffällt. Viele Unternehmen setzen bei ihrer Entwicklung auf Scrum (oder zumindest auf das, was sie dafür halten) und führen im Zuge dessen auch tägliche Meetings, sogenannte Dailys, durch. Dabei muss ich ehrlich zugeben, dass ich bisher noch kein Unternehmen kennengelernt habe, bei dem ich die Dailys als produktiv oder gar hilfreich empfunden hätte. Meistens hatte ich stattdessen genau die gegenteilige Meinung: Die Dailys waren langweilig und ineffizient und aus meiner Sicht komplett überflüssig.

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Natürlich möchte ich mich dabei nicht als das Maß der Dinge darstellen, doch nachdem ich wirklich viele Unternehmen von innen gesehen habe, fällt mir eben auf, dass zwar das Konzept des Daily-Meetings einerseits weitverbreitet zu sein scheint, die Umsetzung andererseits jedoch häufig keinen guten Eindruck hinterlässt. Hier liegt anscheinend ein Problem vor, über das man mal sprechen sollte. Denn: Warum sind Dailys denn so oft eine Katastrophe? Warum werden sie dennoch durchgeführt? Und gibt es Möglichkeiten, sie besser zu gestalten? Auf all diese Fragen möchte ich in diesem Artikel eingehen.

Wenn man sich fragt, wo eigentlich die ursprüngliche Idee für ein Daily-Meeting herkommt, werden vermutlich viele Entwicklerinnen und Entwickler antworten, dass es sich dabei um ein Konzept aus Scrum handelt. Ob die Idee der Dailys wirklich für Scrum erfunden wurde oder ob Scrum die Idee lediglich populär gemacht hat, weiß ich nicht, aber es lässt sich sicherlich festhalten, dass ein Zusammenhang zwischen der Verbreitung von Scrum und der Durchführung von Dailys zu bestehen scheint.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Die Frage, die sich nun stellt, lautet: Was ist eigentlich ein Daily? Ich habe einige Quellen zurate gezogen, darunter auch die Website scrum-master.de, welche das Daily als "kurzes, tägliches Statusmeeting des Teams" definiert. Im Vergleich dazu erwähnt der offizielle Scrum-Guide das Wort "Status" nicht, beschreibt das Daily aber als ein 15-minütiges Treffen des Scrum-Teams. Ziel sei es, einen Einblick in den Fortschritt bezüglich des Sprint-Ziels zu bekommen und das Backlog auf Basis neuer Erkenntnisse für zukünftige Sprints anzupassen. Obwohl der Begriff "Status" dort also nicht explizit verwendet wird, zielt die Fragestellung im Kern dennoch darauf ab: "Wie steht es um den Fortschritt?"

Hier beginnen meiner Meinung nach bereits die Probleme. Nehmen wir diese beiden Definitionen als Ausgangspunkt, so ergibt sich die Frage: Wer nimmt an einem solchen Daily eigentlich teil? Die Antwort ist in beiden Fällen ziemlich klar: das "Team" beziehungsweise das "Scrum-Team". Bloß, was versteht man unter einem Team in Scrum? Es handelt sich um eine Gruppe von Personen, die für die Erstellung des Produkts essenziell sind und bewusst aus verschiedenen Disziplinen – von der Entwicklung über Design und Marketing bis hin zur Planung und Organisation – zusammengesetzt ist. Laut dem offiziellen Scrum-Guide gehören zu diesem Team ausdrücklich die Rollen des Product Owners und des Scrum Masters.

Es könnte natürlich sein, dass dies in Ihrem Unternehmen anders gehandhabt wird, als ich es bisher kennengelernt habe. Möglicherweise ist bei Ihnen die Rolle des Product Owners tatsächlich darauf beschränkt, an der initialen Sprint-Planung teilzunehmen und später den Review durchzuführen. Aber in den meisten Fällen ist der Product Owner sehr daran interessiert zu erfahren, wer gerade woran arbeitet und wie die Projekte voranschreiten. Das geht so weit, dass diese Fragestellung des Product Owners in der Regel sogar die treibende Kraft hinter dem Daily ist. Wie zuvor erwähnt, es mag bei Ihnen anders sein, ich spreche hier nur von meinen Erfahrungen.

Das Hauptproblem dabei ist, dass das Daily auf diesem Weg in erster Linie zu einem Statusmeeting für Product Owner avanciert. Statt dass sich die Teammitglieder auf Augenhöhe austauschen, erfolgt oft ein Bericht an die – gefühlte oder tatsächliche – nächsthöhere Hierarchieebene. Bedenkt man, dass ein Team nach Scrum-Definition 7 +/- 2 Mitglieder umfassen sollte, so mag ein Meeting zwar auf der Uhr nur 15 Minuten dauern. Doch in Wirklichkeit sind, rein kostenmäßig betrachtet, bei 7 Teammitgliedern ganze 105 Minuten Arbeitszeit investiert worden – also fast zwei Stunden pro Tag.

Rechnet man das hoch, summiert sich das auf rund 10 Stunden pro Woche und annähernd 40 Stunden im Monat, die allein für die Dailys aufgewendet werden. Das bedeutet, dass durch die Dailys jeden Monat die Arbeitskraft einer ganzen Personenwoche verloren geht. Für ein bloßes Statusmeeting sind das aus meiner Sicht unverhältnismäßig hohe Kosten. Es handelt sich schlichtweg um eine Verschwendung von Zeit und Geld.

Aber das ist nicht das einzige Problem. Wenn ein solches Meeting zu einem Statusreportmeeting wird, entstehen für alle Teammitglieder Stress und Druck, weil sie das Gefühl haben, ständig etwas berichten zu müssen. Niemand möchte den Eindruck erwecken, nicht zu arbeiten. Deshalb wird notfalls irgendetwas erzählt, um irgendeinen Fortschritt vorzeigen zu können. Oft sind es dann tiefgehende technische Details, die für niemanden sonst im Team von echtem Interesse sind. Es scheint besser, irgendetwas Kompliziertes zu sagen, als einzuräumen: "Eigentlich gibt es gerade nichts Neues bei mir."

Wer das bezweifelt, sollte es einfach mal ausprobieren: Berichten Sie einige Tage lang nichts Neues und beobachten Sie, wie lange es dauert, bis Sie darauf angesprochen werden, warum es nicht vorangeht, was Sie derzeit überhaupt machen, und so weiter. Und hier zeigt sich die wahre Problematik: Aus einem harmlos wirkenden Statusreport wird schnell ein Kontrollmeeting, in dem geprüft wird, ob jede und jeder auch wirklich arbeitet. Es scheint, als könnte man nicht einfach darauf vertrauen, dass Sie eigenständig und diszipliniert arbeiten und sich melden, wenn es etwas zu berichten gibt – sei es positiv oder negativ.

Bezüglich dessen, was man in einem Daily Meeting idealerweise sagt, hat sich in vielen Unternehmen ein festes Muster etabliert, nämlich die berühmten drei Fragen: Was hast du gestern gemacht? Was machst du heute? Wo gibt es Probleme?

Diese werden von jedem Teilnehmer des Meetings routinemäßig beantwortet: "Ich habe gestern dies und das gemacht, heute werde ich jenes tun, und es läuft gut, ich habe aktuell keine Probleme." Es ist äußerst ermüdend, wenn diese Formel täglich von jeder und jedem ohne Variation wiederholt wird und der Informationsgehalt für die anderen Teammitglieder meistens gering ist.