Seite 2: Das Daily schadet der Dynamik

Inhaltsverzeichnis

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)