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?
(Bild: GaudiLab/Shutterstock.com)
- Golo Roden
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.
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.
Zur Idee der Dailys
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?"
Die Zielgruppe
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.
Es sind doch nur 15 Minuten …
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.
Psychische Konsequenzen
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.
Das 3-Fragen-Muster
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.
Das Daily schadet der Dynamik
Ich frage mich an der Stelle oft: Warum sollte ich, wenn ich etwas Wichtiges mitzuteilen habe, bis zum nächsten Daily warten? Das erscheint mir ineffizient, und es verzögert alles. Zudem nimmt es, zumindest bei guten Neuigkeiten, auch die Begeisterung. Wenn ich etwas Bedeutendes erreicht habe, das für das Team wichtig ist, möchte ich das doch gerne sofort teilen und nicht erst am nächsten Montag, weil das Daily am heutigen Freitag leider schon vorbei ist.
Gleiches gilt, wenn ein Problem auftritt – warum sollte ich Stunden bis zum nächsten Tag warten, um es anzusprechen? Und offen gesagt: Wenn jemand wissen möchte, woran ich derzeit arbeite, kann sie oder er mich einfach direkt fragen, oder einfach selbst nachsehen, beispielsweise im Projekt-Board – dafür ist es doch schließlich da. In der Mehrzahl der Tage gibt es aber einfach nicht viel Neues zu berichten, und alles, was ich dann wirklich möchte, ist, ungestört arbeiten zu können und nicht aus meiner Konzentration herausgerissen zu werden, weil das nächste unnötige Statusreportmeeting ansteht. Kurz gesagt: Ich habe meine Zweifel am Nutzen von Dailys.
Wie bereits erwähnt, kann es natürlich sein, dass das bei Ihnen alles komplett anders läuft. Persönlich habe ich Dailys allerdings noch nie als positiv erlebt, und das gilt unabhängig von der Art des Unternehmens. Die Probleme, die ich beschrieben habe, sind mir sowohl aus Start-ups als auch aus Großkonzernen bekannt, ebenso aus Unternehmen mit flachen Hierarchien wie aus solchen mit stark ausgeprägten Hierarchiestrukturen. Und diese Erfahrungen sind unabhängig davon, wie agil ein Unternehmen arbeitet (oder zu arbeiten glaubt, denn oft sind die vermeintlich agilen Unternehmen gar nicht wirklich agil). Falls Sie jetzt denken, dass es in Ihrem Unternehmen tatsächlich anders zugeht, würde ich mich freuen, wenn Sie Ihre Erfahrungen in den Kommentaren zu diesem Artikel teilen würden.
Alternativen zum Daily?
Nun ist es natürlich immer einfacher, Kritik zu üben, als konstruktive Verbesserungsvorschläge zu machen. Aber ich glaube, es ist an dieser Stelle gar nicht so schwierig, eine Verbesserung vorzuschlagen. Wie ich schon angedeutet habe: Ich möchte im Bedarfsfall nicht warten müssen, bis das nächste Daily stattfindet. Daher erscheint es mir sinnvoller, Kommunikation nach Bedarf zu ermöglichen. Haben Sie etwas erreicht, das das gesamte Team interessieren und freuen wird? Teilen Sie es direkt mit. Stehen Sie vor einem Problem, bei dem Sie schon länger feststecken, und würden gerne mit jemand anderem darüber sprechen? Suchen Sie direkt nach Unterstützung. Müssen Sie ein Konzept diskutieren, um weiterzukommen? Warten Sie nicht auf das nächste Daily, sondern sprechen Sie es direkt an. Ad-hoc-Kommunikation halte ich in einem Team von 7 +/- 2 Personen für weitaus sinnvoller, effektiver und effizienter als die üblichen, ineffektiven Dailys.
Natürlich könnten Sie jetzt einwenden: Nicht jede Person hat immer sofort Zeit. Das ist korrekt, und genau deshalb ist asynchrone Kommunikation so entscheidend. Ich meine also nicht, dass Sie, wenn Sie etwas Interessantes zu berichten haben, alle sofort zusammenrufen sollten. Vielmehr: Wenn Sie etwas Spannendes zu berichten haben, dann teilen Sie das beispielsweise im Team-Chat. Oder, wenn es sich um ein Feature handelt, das sich in der Benutzeroberfläche zeigt, machen Sie ein kurzes Video oder einen Screenshot und posten Sie das. Wenn Sie ein Problem haben, fragen Sie im Team-Chat, ob jemand, der sich in dem Bereich auskennt, Zeit hat, um sich mit Ihnen zusammenzusetzen. Und so weiter.
Direkt zu handeln, statt im Daily zu berichten, bedeutet nicht, dass Sie immer alle sofort informieren müssen. Es ist völlig in Ordnung, wenn Ihr Team die Nachricht vielleicht erst einige Stunden später oder sogar erst am nächsten Tag sieht – ähnlich wie bei einem Post in sozialen Medien, den nicht alle Ihre Freundinnen und Freunde sofort sehen. Und wenn wirklich dringender Handlungsbedarf besteht, dann können Sie immer noch alle zusammentrommeln. Aber selbst dann ist es sinnvoller, das direkt zu tun, statt auf das nächste Daily zu warten. Also, ganz egal, wie man es betrachtet: Ich persönlich sehe keinen Sinn darin, warum ich etwas bis zum nächsten Daily aufschieben sollte. Ich persönlich halte das schlichtweg für Quatsch.
Meine persönliche Erfahrung
Entsprechend dem, was ich bis hierhin geschrieben habe, haben wir bei the native web keine Dailys. Tatsächlich haben wir überhaupt keine regelmäßigen Meetings, mit einer Ausnahme, auf die ich gleich noch kommen werde. Bei uns erfolgt immer alles ad-hoc, und damit sind wir seit nunmehr etwa 12 Jahren insgesamt sehr erfolgreich und zufrieden. Der große Vorteil dabei ist, dass wenn Sie etwas direkt ansprechen, Sie sich auch aussuchen können, wen Sie damit ansprechen. Das bedeutet, die Relevanz des Themas für die Personen, die ad-hoc zusammenkommen, ist wahrscheinlich viel größer als in einem Daily, wo alle sich stets alles anhören müssen. Und da ich erwähnte, wie wichtig asynchrone Kommunikation ist: Bei uns läuft das hauptsächlich über Slack.
Die einzige Ausnahme ist ein informelles wöchentliches Treffen, bei dem wir uns einfach zum informellen Austausch treffen, und wo gegebenenfalls noch Themen angesprochen werden können, die wirklich für alle relevant sind und die nicht bereits dringend waren. Und damit sind wir, wie zuvor erwähnt, sehr zufrieden.
Keine Wunderwaffe
Eines möchte ich jedoch noch klarstellen: Ich gebe mich nicht der Illusion hin, dass unsere Methode die magische Lösung für alle Probleme darstellt, egal in welchem Unternehmen Sie tätig sind. Was es jedoch definitiv zeigt, ist, dass es Alternativen gibt. Das bedeutet: Führen Sie keine Dailys durch, nur weil "man das in Scrum eben so macht" oder weil "es jeder macht". Entscheiden Sie sich stattdessen für Vorgehensweisen, die zu Ihnen passen und die tatsächlich einen Mehrwert für alle im Team bieten, und nicht nur für den Product Owner.
Wenn ein Großteil des Teams das Gefühl hat, ein Meeting sei eher Zeitverschwendung, dann sollten Sie darüber nachdenken, warum Sie dieses abhalten, welchen Zweck es erfüllen soll und welche Intention dahintersteckt, um dann alternative Wege zur Erreichung dieser Ziele zu suchen. Denn – und das ist das Wesentliche – Sie sind nicht dazu da, Scrum & Co. zufriedenzustellen. Vielmehr sollten Scrum & Co. dazu dienen, Sie zu unterstützen.
Stellen Sie Ihre Bedürfnisse und Anforderungen als Team also nicht zurück, nur weil ein Prozess oder ein Werkzeug dies von Ihnen verlangt. Die Prozesse und Werkzeuge sind da, um Ihnen zu helfen, nicht umgekehrt. Das ist übrigens der Kerngedanke der gesamten Agilität und tatsächlich der erste Punkt des Agilen Manifests: „Menschen und deren Interaktionen sind wichtiger als Prozesse und Werkzeuge.“ Auf Englisch: „Individuals and interactions over processes and tools.“ Und das sollten Sie nie vergessen. (rme)
