Heute mal kein Daily … // deutsch

[@thenativeweb]

Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Das-Daily-muss-heute-leider-ausfallen-9684706.html

[@wasauchimmer]

Danke Golo, tut gut, dass man mit diesen Gedanken nicht alleine ist.

[@MrPopel]

Je größer die Gruppe/Team, um so unsinniger wird das Daily - meine Beobachtung.

[@sentou31]

Bei meinem letzten Arbeitgeber war es tatsächlich so, das die PO sich nach ein paar Wochen (aus persönlichen Gründen) aus dem Daily zurückgezogen hat. Scrum-Master gab es, aus Gründen auch nicht. Seit diesem Zeitpunkt waren viele dieser "Reporting" Aspekte die du genannt hast komplett verschwunden. Reporting wurde nur noch über Jira-Tickets gemacht. Wir haben zwar immernoch über den aktuellen Status gesprochen, allerdings eher punktuell. Zum Beispiel: Ein Release steht an und es gibt organisatorische oder technische Dinge zu klären, die alle Betreffen. Oft war auch noch Zeit für die typische Kaffee-Plauderei am Ende, die ja durch remote fast komplett verloren gegangen sind. Keiner hat gestört und der Druck war raus. Gerade die Tatsache, das diese 30 minütige Meeting ohne "Agenda" abgelaufen ist, hat die Arbeitsamossphere aufgelockert. Oft habe ich die Dailies als produktiver empfunden, da ich nicht in einem random Planning-Meeting sitzen musste bei dem ich nur zu 20% der Themen etwas beizutragen habe.

[@dirkj.3234]

Die Dailies sind neben der inhaltlichen Abstimmung auch eine gute allgemeine Team-Kommunikation, besonders morgens zum Start. In Zeiten wo jeder 80%+ alleine zuhause sitzt, geht ansonsten Team-Gefühl und menschliches Miteinander verloren. Asynchrone Kommunikation zwischen zwei oder drei Kollegen ist zielorientiert aber kann das nicht ersetzen. Und manche Dinge sind dann eben auch teamweit interessant. Wir machen aktuell drei "Dailies" pro Woche.

[@M.B-z8d]

Stichwort "ad hoc Kommunikation": Ist in scrum guide explizit erwähnt und niemand behauptet, dass das daily scrum diese ersetzt. "The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work."

[@marcusreinicke]

Guten Mooorgääähn Golo. Ich bin da voll bei Dir. Ich habe auch schon einige Dailys miterlebt und sehe das genauso.

[@m83555]

Ich mach mit meinem Team mittlerweile nur noch 2 mal pro Woche ein "Daily". Und wir sind jetzt weg von Scrum und machen Kanban mit einer stark an unserer Arbeitsweise angepassten Variante. Ich hab die Kollegen auch dafür sensibilisiert, nur etwas zu einer Swimlane (die sind bei uns projektbasiert) zu sagen, wenn es für andere relevant ist. Hier hilft auch die starke projektfokussierung. Anstatt personenzentrisch bei Scrum, bei der klassischerweise jede Person einzeln etwas berichtet (und natürlich jeder etwas/viel sagen wird!), ist jetzt alles auf die Projektthemen fokussiert. Für alles andere gibt es unseren internen Chat oder klärt es per Anruf. Wir vermeiden sonstige Meetings, und vor allem Regelmeetings, wo es nur geht. Jetzt sind alle viel glücklicher als vorher mit Scrum (nach dem Lehrbuch). Meiner Meinung nach sollte man agile Methoden immer an das Team und deren Bedürfnisse anpassen und Cherry Picking betreiben. Ein starres Durchführen nach Lehrbuch ist häufig alles andere als optimal.

[@dominolehmann8227]

Selbst scrum bzw das agile manifesto sagt ja, dass es ein framework ist und man sich selektiv davon bedienen soll.

[@katzchenundloup6693]

5:50 Vom Statusreport zum Kontrollmeeting: Genauso lief/läuft es bei uns. Besonders das "was war gestern, was machst Du heute". Ich hab's immer gehasst... Die Gedanken kreisten am Abend (im Feierabend!) schon darum "was sag ich morgen bloß wieder?"

[@Tekay37]

Bei uns ha die Pandemie und die Einführung von HomeOffice dazu geführt, dass wir von 0 auf 3 Meetings am Tag gewechselt sind. D.h. ich als einziger Programmierer im Unternehmen muss auch Themen zuhören, die für meine Arbeit nie relevant sind. Aber ich muss halt aktiv zuhören, was welcher Kunde gerade so will, weil ich dann gleich mithören kann falls da auch was für mich dabei ist (passiert ca. 2-3 Mal im Monat). Anfangs habe ich während des Meetings einfach weitergearbeitet, aber das war dann auch nicht gerne gesehen, weil ich dann halt nicht zuhöre. Ich bin also seitdem täglich 1-2 Stunden meiner Arbeitszeit dazu verdonnert, unproduktiv zu sein (ja, ich verliere einen vollen Arbeitstag pro Woche). Monatsmeeting haben wir auch, und das ist tatsächlich gut, aber ich finde es wichtig, Montagsmeetings grundsätzlich nicht Montags durchzuführen.

[@birqan]

1. Der Product Owner ist nicht Teil des Teams und sollte dem Daily aus genau den Gründen die du auch erwähnst hast fern bleiben. 2. Das Daily ist auch dazu da, introvertierte Kollegen aus dem Team, die in der IT keine Seltenheit sind, dazu zu bringen zu kommunizieren. Wenn man denen die Wahl lassen würde, würden sie sich allmählich ganz zurückziehen.

[@Honkstar]

Falsch. Der PO kann sich auch einfach zurückhalten. Einfach mal den offiziellen Scrum Guide lesen.

[@obstmi]

Glücklicherweise treffen in unserem Team die genannten negativen Aspekte nicht zu - das Daily mutiert weder zu einem Status- noch Kontrollmeeting. Wir halten es knapp, jede/r sagt zwar (sinngemäß) kurz, was er/sie gestern gemacht hat und heute vor hat (inkl. dem PO), aber das stört nie. Im Gegenteil: da wir remote arbeiten und zudem über Europa verteilt sind, würden wir sonst gar nichts voneinander mitbekommen. Klar können sich alle den Fortschritt in Jira anschauen, aber dann entwickelt sich der tägliche Arbeitsablauf doch zu einer totalen Nerdveranstaltung und das menschliche Miteinander und der Teamgeist bleiben komplett auf der Strecke. Fachlich ist es genauso wertvoll: es gibt (fachliche) Fragen an den PO, technische Fragen vom PO und Fragen oder Tipps der Entwickler untereinander. Und falls es nichts Neues zu sagen gibt: dann ist es halt so und der/die nächste ist dran. Fazit: ich möchte das Daily keinesfalls missen und es ist unser wichtigstes Meeting überhaupt. Und ad hoc Kommunikation findet bei uns natürlich auch statt. Entweder im Chat oder per Videochat. Bei allen spontan auftretenden Themen, bei Fragestellungen, die nicht alle Teammitglieder interessieren oder bei Themen, die tiefergehend diskutiert werden müssen.

[@bjornzschernack7653]

Man nimmt die auch nicht mehr Ernst. Das ist eher so eine Art Pause mittlerweile..und man lacht halt viel 😅

[@BBirke1337]

Einen Nutzen haben die Dailies zumindest bei Homeoffice: man fängt frühmorgens zu einer bestimmten Zeit an, sie geben Struktur. Das Reporting ist zwar nicht der gewünschte Effekt, aber es lässt sich auf max. 30 Sekunden für jeden Entwickler reduzieren, der eigentlich nichts zu sagen hat. Bohrendes Nachfragen, "was tust du eigentlich?", ist aber hier toxisch und nicht zu gebrauchen.

[@DeLayDev]

In meiner alten Firma war es genauso wie du es hier beschrieben hast. Eigentlich ein Statusmeeting für den PO, wenn dieser nicht teilgenommen hat war das meistens kürzer. Es wurden Fachliche Fragen geklärt und meistens kam auch noch dann die Frage wann den Issue XY endlich abgeschlossen ist. Nach 15 Minuten musste meistens ein harter Cut gemacht werden und oft waren noch nicht mal alle Entwickler dran gewesen. War oft eins der stressigsten Meetings des Tages. in meinem aktuellen Projekt ist es um einiges angenehmer. Nicht jeder erzählt seinen Status, sondern wir gehen die Issues im Project Board durch welche gerade bearbeitet werden. Und falls unser ScrumMaster noch ein paar allgemeine Infos hat gibt es die auch noch. Obwohl wir 7 Devs + SC + PO sind reichen die 15 Minuten für alles ohne Probleme aus. Fragen werden direkt kommuniziert wenn sie auftreten, genauso Status Updates wegen Code Reviews oder einer PO Abnahme.

[@Honkstar]

Wer ein Daily an hand der Fragen an statt der Stories führt hat eh den falschen Focus. Es geht um den Fortschritt der Sprintinhalte nicht um das was jeder reported...!

[@mazedlx]

In einem aktuellen Projekt wird das Daily gerne als Ersatz für ein richtiges Meeting (natürlich ohne Agenda) zweckentfremdet. Hochgradig sinnfrei.

[@NeroG4ming]

haha unser tägliches Developer Daily ist dank unseres Abteilungsleiters zu einem Abteilungsdaily geworden, wo dann >20 Personen dran teilnehmen und das geht gut und gerne mal 30 minunten. JEDEN TAG. Grund: "Dann wisst ihr was andere Kollegen aus anderen Abteilungen machen" Wurde so oft schon angesprochen, dass es mich nicht interessiert, ob Mitarbeiter aus der IT gerade an der Firewall werkeln oder sonst was. Genauso juckt es niemanden, an welchen Klassen ich gerade arbeitet usw.

[@thenativeweb]

🙈🙈🙈

[@till3439]

Danke! Kann dir nur zustimmen.

[@ragnar-the-giant]

Hi Golo, interessant zu hören, wie es so in anderen Firmen gehändelt wird. Bei uns gehen wir die Stories des Sprints von oben nach unten durch und jeder der dazu was zu sagen hat, erzählt etwas dazu. Am Ende nutzen wir das Dailiy, tatsächlich für Status updates und für Absprachen mit den POs. Meist sind kleinere Fragen diesbezüglich vorhanden. Bei uns geht ein Daily in der Regel 10 Minuten.

[@smanneck]

Statt dass reihum jeder irgendetwas erzählt, ist es viel sinnvoller, durch das Board (von rechts nach links) zu gehen und die relevanten Änderungen im Ticket mit den anderen zu teilen.

[@YTLaLi]

Sehe ich nicht so, im Zeitalter von Homeoffice ist es wichtig, dass man sich wenigstens virtuell einmal am Tag sieht/trifft. Ad hoc Meetings haben das Problem, dass man ersteinmal einen gemeinsamen Termin finden muss (während das Daily bei Allen eingeplant ist). Kaum ein Problem bzw. eine Info ist so dringend, dass diese/s nicht bis zum nächsten Daily warten könnte und wenn doch, kann man im Slack jemanden anchatten. Kommunikation ist nun mal Aufwand. Für einen Softwareentwickler, der ja eher vor sich selbst dahinarbeitet mag nicht jedes Daily notwendig sein, aber bei Tätigkeiten die mehr Abstimmung mit anderen Kollegen erfordern ist es wertvoll.

[@HarryVivi]

Wir haben uns in einer sehr heißen Projektphase für dailies entschieden, sind aber relativ schnell auf 2 Meetings die Woche runter gegangen. Nach dem Launch sind wir zu einem weekly umgeschwungen. Und das ist sehr gut so - eben genau die direkte Kommunikation ist das was wichtig ist. Ich denke aus dieser Eigendynamik kriegt man auch ein gutes Gefühl für die Kollegen (Arbeitsweise etc.)

[@WolfgangEgger]

Ich hab's glaub ich schon mal geschrieben. Dieser ganze Scrum-Humbug hat dazu geführt, dass ich vor ein paar Monaten nach mehr als 30 Jahren Softwarentwicklung den Brocken hingeworfen hab. Früher hab ich mit den Benutzerinnen meiner Software direkten Kontakt gehabt und wir haben auf diese Weise ermittelt, was sie wollen und sie haben mir direkt gezeigt, wenn etwas nicht ihren Wünschen entsprach oder sie haben mir die Fachlichkeit erklärt, wenn ich etwas nicht verstanden hab. Zum Schluss hab ich ein Drittel meiner Zeit mit Meetings mit einer Mangement-Ebene verbracht, die keine Ahnung von Technik und kaum Ahnung von der Fachlickeit hatte und die sich dann, um ihre Existenz zu rechtfertigen hinter Formalismen verschanzt hat. Also das Gegenteil des ersten Satzes des Agilen Manifestes. Die Produktivität ist dabei von Jahr zu Jahr gesunken, mit der irrwitzigen Folge, dass die Managemet-Schicht von Jahr zu Jahr erweitert wurde. Alles mit fach- bzw. betriebsfremden Menschen, so das der Skilllevel von Jahr zu Jahr gesunken ist. Auf diesen ganzen Mist hab ich einfach keine Lust mehr. Das macht null komma gar keinen Sinn

[@AndreasJung]

Na ja...Kommunikation außerhalb des Daily zwischen Team-Mitgliedern ist üblicherweise was man halt so macht...Die Schilderung, dass man immer bis zum Daily wartet, ist auch eher die Ausnahme...eine etwas zu polarisierte Darstellung, die sich mit meiner Erfahrung aus 20 Jahren Freelancertätigkeit nicht so deckt.

[@djchrisi]

Wir haben ein Microblogging in der Art von Twitter eingeführt. Jeder schreibt am Tag 2-3 Beiträge, was er so gerade macht, was klappt, was nicht. Nur einen oder zwei kurze Sätze, keinen Aufsatz. Das dauert nicht lange, und die Product Owner und alle anderen können trotzdem sich einen Überblick verschaffen.

[@LA-fb9bf]

Dailies sind cool. Ist wie ein morgendliches Briefing. Man weiss, was die Leute so machen. Zeit wird für andere Dinge eher verschwendet als für ein Daily

[@qui-gonkenobi4574]

ja das kann ich bestätigen, das Daily ist echt zu einem Kontrollmeeting geworden und man ist unter druck irgendwas zu sagen, obwohl ich die ganze Zeit davor gearbeitet habe. Blöd auch, wenn ein Bug, schlecht zu finden war und die Änderung nur ein Zeichen benötigte :D

[@nilsmach6399]

Vor allem hat ein Product Owner bei dem Daily überhaupt nichts verloren. Das steht sogar explizit im Scrum Guide. Das Daily ist ausschließlich Sache der Developer. Außerdem ist der PO auch kein Manager, an den man den Status reporten muss. Die Aufgabe des Product Owner ist ausschließlich, die Pflege und Priorisierung des Backlogs. Es ist eine reine Zuarbeit für das DEV-Team. Damit sich die Entwickler damit nicht so viel beschäftigen müssen. PO ist weder Raketenwissenschaft noch Management. Das einzige Problem, diese Rolle wird von BWLern und generell Leuten aus dem Business übernommen, die sich nicht auf ihre Rolle beschränken wollen, sondern sich doch wie ein Manager aufführen und damit den ganzen agilen Prozess ruinieren.

[@Honkstar]

Falsch. "Der zentrale Bestandteil von Scrum ist ein kleines Team von Menschen, ein Scrum Team. Das Scrum Team besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt-Ziel."

[@nilsmach6399]

@@Honkstar „The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.“ Für die Entwickler des Teams! Nur wenn Scrum Master oder PO auch mitprogrammieren können sie teilnehmen, aber dann, wieder explizit, in ihrer Rolle als Entwickler.

[@orange-vlcybpd2]

In opensource funktioniert es irgendwie mit ausschließlich asynchroner Kommunikation und bei internationaler Besetzung seit Jahrzehnten.

[@ViktorEngelmann]

Bei uns ist das Daily eine ganze Stunde. Jeden Tag. Mit 8 Mitarbeitern. Da wird also sogar eine komplette Stelle verpulvert nur damit der PO 8 Einzel-Gespräche führen kann, während denen der Rest des Teams Däumchen dreht.

[@ViktorEngelmann]

"Agil" bedeutet bei uns auch, dass der PO die Tickets den einzelnen Mitarbeitern direkt zuweist und damit (weil alle Tickets hohe Priorität haben, weil jeder Berater seine Kunden halten will) nicht zum nächsten Sprint-Planning warten kann. In anderen Worten: überhaupt nicht "Agil".

[@thedrumify]

Ich glaube für Teams, die größtenteils für sich arbeiten, ist das daily eine tägliche Teambildung Maßnahme (geteilte Freude ist vielfache Freude, geteiltes Leid ist weniger leid). Auch wenn man überlegt wie viele Unterbrechungen wegfallen durch Bündelung der News und wie viel besser die News eingeordnet werden können durch direkte Nachfragen (warum hat Kunde sich genau beschwert, weche Auswirkungen hat das für uns als Team, gibt es positive Nachrichten an anderer Stelle, ..). Ich glaube für manche Teams macht es Sinn die Termine täglich zu haben.

[@bios41]

Ja für Reporting völlig überflüssig. Jedoch für den Sync im Homeoffice mit den Kollegen unabdingbar

[@wassagtmanndazu]

Es hängt von den Persönlichkeiten ab. Dass alle selbstbewusst eigenen Bedarf und eigene Probleme adhoc ansprechen, ist nicht selbstverständlich. Insbesondere wenn noch Rivalitäten, Unsicherheiten, Ängste, Egomanen, Wichtigtuer oder einfach anstrengende Menschen eine Rolle spielen - um nur ein paar zu nennen. Egal ob Produktowner, Programmierer, Chef oder … Hier hilft ein menschlich flexibler, fähiger Scrummaster enorm. Aber auch nicht zu häufige, aber auch nicht zu seltene Dailys. Denn wenn man ständig unterbrochen wird, ist das schlecht für die Produktivität. Zu wenig Abstimmung natürlich gleichermaßen.

[@thomaseichinger1717]

Interessant. Ich kann beide Seiten sehr gut verstehen. Einerseits möchte man wissen wie es gerade im Team läuft andererseits möchte man sich nicht immer treffen, denn es verbraucht sehr viel Zeit. Meine Lösungen dazu sind das Arbeitsprotokoll. Das muss sowieso jeder ausfüllen. Da steht drin woran man gerade arbeitet. Das weitere ist dass man einen Gruppenchat/Gruppenticket hat, da haut man dann das Problem rein. Allerdings triftet das zu sehr in „wenig Soziales“ zusammenarbeiten aus. Da bin ich noch ein Fan von gemeinsamen Pausen wo dann die Leute sich besser kennen lernen und da sprechen dann die Leute auch das Problem an. Ich spreche da aber über Development Meetings. Andere Meetings sind da schon wichtig. Bin also absolut bei dir!

[@GoreCode]

Wieder gutes Video. Bei mir war das bisher mit den Meetings immer genauso. Im Grunde recht sinnlos. Bei meiner aktuellen Firma ist das anders. Da gibt es ein Daily von Montag bis Donnerstag, geplant 30 Minuten. Das Team besteht aus 7 Personen plus Product Owner. Der PO und drei andere aus dem Team sind nur dabei, wenn explizit benötigt (werden dann vorher informiert). Ansonsten sind das nur vier Personen die aktiv am Tagesgeschäft beteiligt sind und wo die unterschiedlichen Arbeiten oft Schnittpunkte haben. So ist man über Änderungen oder Anpassungen gleich informiert und kann nachfragen stellen. Wenn mal nicht wirklich was zu besprechen ist, ist das Meeting auch schon einmal nach ein paar Minuten vorbei. Gefühlt ist das immer recht informativ und sinnvoll. LG

[@michaelbrilz8726]

Guten Morgen Golo, wir machen es genau so wie du. Wir haben nur montags eine kurze Besprechung, wo jeder kurz zusammenfasst, was er letzte Woche gemacht hat und was diese Woche ansteht.

[@ChristophGranz]

Bei überwiegend remote-Arbeit wurde das Daily von jüngeren Kollegen gewünscht. Grundsätzlich hilft wechselnde Moderation. Stimme aber in vielen Punkten mit dir überein.

[@felixkoller5871]

Hallo, ich arbeite als Agile Coach und Scrum Master und wollte hier kurz einwenden, dass der so nicht ganz stimmt was du sagst. 3:03 Der Scrum Guide sagt hier, dass es ein Event der Developer ist und ergänzt sogar, dass Scrum Master und Product Owner nur erforderlich sind, wenn sie Aufgaben eines Developers im Sprint übernehmen. Ansonsten müssen Sie in diesem Event nicht teilnehmen. Leider wird das in sehr sehr vielen anders gehandhabt. Der Fehler ist aber dennoch bei den Organisationen oder Teams zu suchen, als beim Konzept selbst, denn nur der Ansatz das Event als „Status Update“ Event anstatt es als Planungsevent für den Tag zu betrachten, macht es zu einem oft schlechten und nicht zielführenden Meeting

[@felixkoller5871]

Ich will nicht zu viel anmerken, weil das Video an sich super ist und in vielen Teilen die Realität widerspiegelt, aber zB auch die typischen 3 Frage sollten so nicht Teil des Dailies sein. Sie wurden sogar mit dem Scrumguide 2020 aktiv aus dem Guide entfernt. Das Daily sollte als reines Planungsevent für den Tag gesehen werden. Natürlich sollen erfolge und sonstiges auch zwischendrin kommuniziert und entsprechend gefeiert werden. Niemals sollte das Daily jemanden davon abhalten über den Tag mit sienem Team zu kommunizieren. Leider wird genau das in vielen Teams einfach falsch gelebt oder durchgeführt. Das liegt häufig genug daran, dass selten nach dem "Warum" eines Events gefragt wird, und häufig nur nach bestem Wissen gemacht wird. Also nochmal. Sehr gutes Video. Sehr viele realitätsgetreue Schilderungen, nur schade, dass du (aus meiner Scrum Master Sicht) die falschen Ursachen benennst. Denn durch solch eine Darstellung wird leider genau dieses falschen durchführen eines Daily Scrum Events weiter in die Köpfe (zurecht) frustrierter Entwickler, Tester, Product Owner und anderer getragen. Das letzte Kapitel trifft den Nagel allerdings auf den Punkt. Weder Scrum, noch Kanban, SAFe oder welche Methodik bzw Framework auch immer man als Grundgerüst wählt, am Ende geht es darum wege zu finden, die für das eigene Team/die Organisation effektiv und wenn möglich auch effizient sind :) LG Felix

[@Honkstar]

Nicht ganz siehe Scrum Guide: "Der zentrale Bestandteil von Scrum ist ein kleines Team von Menschen, ein Scrum Team. Das Scrum Team besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt-Ziel." PO kann teilnehmen, muss aber nicht.

[@felixkoller5871]

​@@Honkstar Der Scrum Guide 2020 versteht unter dem Scrum Team: Scrum Master, PO und Developer, das stimmt. Aber schreibt ganz explizit zum Daily: "Das Daily Scrum ist ein 15-minütiges Event für die Developer:innen des Scrum Teams [...] Falls der:die Product Owner:in oder der:die Scrum Master:in aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er:sie als Developer:in teil." Und darum ging es hier explizit. Teilnehmer des Dailies sind nicht das Scrum Team, sondern die Developer. Und das ist es was die meisten Teams falsch verstehen.

[@svenludwig7435]

Gute Gedanken! Für Remote teams halte ich es für sinnvoll, dass man sich zumindest täglich mal kurz sieht. Aber ja Betonung auf kurz. Und wir machen es zum Start des Arbeitstages, sodass die meisten nicht aus ihrem Tunnel gerissen werden, viele fangen mit dem Daily den Tag an. Ich nehme aber ein paar sehr wertvolle Gedanken mit, die ich mal einfließen lassen werde. Danke!

[@cyrusol]

Hmm. Ich denke der Vorschlag, etwas direkt mitzuteilen widerspricht halt dem Wunsch, nicht immer aus der Arbeit rausgerissen zu werden. Auch etwas in einen Team-Chat zu schreiben, bewirkt genau das.

[@crowATlinux]

Also ich kenne das so, das der Product Owner, dabei sein kann, aber nicht mitmischen darf. Und meiner XP dabei, der Scrum Master muss durchgreifen das es nicht ausartet und die Leute ausbremsen., z.B. Das wird jetzt nicht hier ausdiskutiert, macht das nach den Meeting.

[@cdoubleplusgood]

Vielleicht lebe ich ja auf der Insel der Glückseligen, aber ich bin mit unseren Dailies ganz zufrieden. Um den Druck herauszunehmen, "irgendeinen Fortschritt" berichten zu müssen, gehen wir nicht mehr Person für Person durch, sondern durch die Items auf dem Board. Das war besonders ein Wunsch unser Teilzeit-Mitarbeiter. Warum aber fühlt man sich unter Druck gesetzt? Mir fallen drei Dinge ein: 1. Der Boss setzt einen unangemessen und unnötigerweise unter Druck. 2. Man war wirklich ein bisschen faul... 3. Man fühlt sich unnötigerweise unsicher - ein psychologisches Problem, über dessen Grund man mal nachdenken sollte. Nicht nachvollziehen kann ich die Argumentation bzgl. "aus dem Tunnel herausreißen". Wenn die Uhrzeit feststeht, kann man das doch einplanen. Viel ungünstiger finde ich die Idee der ad-hoc-Kommunikation. Auch wenn sie scheinbar asynchron verläuft, sieht man die Nachricht doch. Und sehr viele haben das dann die ganze Zeit im Hinterkopf und haben das Gefühl, eben doch schnell reagieren zu müssen. Denn auf dem gleichen Kanal können ja Nachrichten hereinkommen, die wirklich sofortiges Reagieren verlangen. Also: Wenn ich schon aus dem Tunnel gerissen werde, dann bitte zu einer vorbestimmten Zeit.

[@fim71]

1:49 Scrum sollte man im englischen Original (Scrum Guide) und der aktuellen Version (2020) lesen. Alle deutschen Übersetzungen, die ich bisher lesen konnte, sind fehlerhaft, falsch übersetzt. Das Daily beispielsweise ist für die Entwickler, nicht das komplette Scrum Team: "The Daily Scrum is a 15-minute event for the Developers of the Scrum Team."

[@hichaeretaqua]

Hätte ich ehre gewusst, dass du deinen heise-online Artikel hier auch noch verarbeitest, hätte ich den ja gar nicht lesen müssen ;-)

[@thenativeweb]

Das Video war sogar zuerst da 😉

[@conqirich5705]

Danke. Ich werde mich mit meinen Kollegen austauschen. Ich bin gespannt wie die das sehen.

[@MibarMe]

Interessant zu hören. Im Studium steht gerade eine Projektarbeit im 10er Team an, in der wir verpflichtend Scrum nutzen müssen. Ich hatte mir, als man uns die Dailies erklärt hat, schon ähnliches gedacht. Mal gucken, wie meine ersten Erfahrungen dazu sein werden. :)

[@DogzDeDoggy]

Ich werde irgendwann ein Buch schreiben über das, was Unternehmen aus agiler Softwareentwicklung gemacht haben.

[@svenludwig7435]

Was würdest du für full remote teams empfehlen? Bei uns sind alle im Home Office, 100%. Haben wenig Meetings aber bei null Meetings hätte man glaube ich zu wenig visuellen, synchronen Kontakt. Wenn man zusammen im Büro sitzen würde, dann wäre es natürlich was anderes.

[@valeridause]

Wo die gesamte Reviews in den Trains stattfinden, da treffen sich sogar 150 Personen und lauschen nur einem, was er so zu berichten hätte. Das sind die Kosten!!! Deswegen aus diesem angeblichen Agilen habe ich auch aufgehört programmieren zu wollen. Denn plötzlich war es nicht mehr kreativ, sondern nur etwas Schein-artiges. Jede tut so, als ob. Und keiner trägt irgendeind Verantwortung. Teammitglieder nicht, genauso Sctum-Master, und PO genau sowenig. Danke für das Video!

[@florianfeilmeier1017]

Sehe ich genau so. Statusmeetings sind immer Zeitverschwendung. Aber Daily, Retro und Planning sind hald nach Scrum Lehrbuch, wahrscheinlich der Hauptgrund warum sich das trotzdem so durchsetzt.

[@ismirdochegal4804]

Es ist interessant. Schade, dass du Dailies noch nie in gut erlebt hast. Bei uns läuft genau das Gegenteil von dem was aufzählst und Daily ist etwas, warum sich jeder im Team schon den ganzen Vormittag freut. Auch wenn wir damit eine Ausnahme sind, freue ich mich trotzdem. Unser Daily geht zwar länger als 15min, ist aber immer auch der Sozial Hub. Wir sitzen alle an verschiedenen Stadtorten und arbeiten remote. Unsere Aufgaben sind klein genug, dass man sie auch an einem halben Tag schaffen kann und dann macht ein anderer den Review davon. So sagt jeder was er am Tag zuvor geschafft hat und dann werden reihum die fast fertigen Steps zum Review verteilt.

[@joergw]

Zum Glück ist das bei uns anders. Wir setzen stark auf asynchrone und bi-laterale Kommnunikation. Allerdings sind die dailies trotzdem lang uns ausufernd. Trotz allem, würde ich aber auch nicht ganz darauf verzichten wollen, da es auch mal gut tut, wenn das gesamte Team sich mal zu einem Zeitpunkt versammeln kann, um sich zu syncen. So ein "weekly" wie bei euch wäre aber vielleicht eine gute Alternative

[@bsdooby]

Wir hatten dann sogar shadow weeklies (um die daylies zu entlasten)…

[@Gentlehag]

Sehr treffend auf den Punkt gebracht.

[@eduardkrieger6192]

Das stimmt vollkommen, bei uns ist das genau so

[@kyrospace]

Wir haben Dailys und AdHoc Kommunikation. Mann muss aber auch sagen das wir eine sehr kleine Firma sind. Somit sind es Team und Firmen Meeting in einem. Gerade bei Kunden Themen finde ich die Dailys dann aber doch sinnvoll.

[@sevensolutions77]

Voll deiner Meinung Golo...

[@iham1313]

kann nur zustimmen. es waren immer und überall reine kontroll und blabla meetings. völlige zeitverschwendung und nur dafür da, das mgmt rechtfertigen zu können, dass aber halt keine issues, reports, etc lesen und zusammenfassen wollen und lieber mit show and tell unterhalten werden müssen. meist bei besserem gehalt und weniger verantwortung. sinnlosest. alleine schon "sprint" nervt: software projekte in der dimension sind keine sprints, sondern marathons. dieses permanente sprinten ist reines verheizen.

[@markusschmidt9425]

und noch böser gerechnet: 7 Personen * 15 Minuten plus 15 Minuten vorher und 15 Minuten später arbeitet doch niemand oder? Wie lange vor einem solchen Termin arbeitet ihr nicht mehr? Es ist doch immer eine "Vorbereitungszeit" und eine Phase in der man sich ärgert über das Meeting. Und schon sind wir bei 45 Min pro Dev pro Tag :-) und somit bei 105 Stunden pro Monat. Der Punkt "asyncrone Adh Hoc" Kommunikation funktioniert nur wenn die Leute auch in die Chats schauen. Ich erlebe das immer mehr das in Firmen die internen Chats komplett leer sind und keine Kommunikation mehr stattfindet. Da schreibt man rein "he ich hab hier grade was lustiges gefunden" und dann gibts ein Tumbleweed ein paar Monate später :-) Ja auch in 100% Remote Corps.. da ist das daily der einzige Pflicht Kommunikationspunkt der Devs..

[@cdoubleplusgood]

Keine Ahnung, was da bei euch los ist... Außer für den Scrum-Master sollte das Daily rein gar keine Vorarbeit benötigen, und Nacharbeit auch nur, wenn beim Daily dazu etwas herausgekommen ist. Ich kann auch dieses "Hochrechnen" nicht verstehen. 15 min sind bei einem Arbeitstag von 8 h ca. 3%. Das kann man jetzt auf eine Woche, ein Jahr oder 1000 Mitarbeiter hochrechnen - es bleiben 3%.

[@mist3rm819]

@@cdoubleplusgood Vorbereitung ist zum Beispiel den aktuellen Stand kurz und präzise wiedergeben zu können. Also überlegen was man beim letzten daily zu seiner Story schon gesagt hat und was seitdem dazugekommen ist. Ich gehe da schon mit, dass 10-15 Minuten vor und nach daily nicht gearbeitet wird.

[@thiirtysix]

bei uns ist es GENAU so wie im video beschrieben. nagel auf den kopf getroffen.

[@bytefresser]

Dem ist definitiv nichts mehr hinzuzufügen😅

[@lameshithead]

mit was für firmen hast du den zu tun`?

[@2xxxtrem]

Gleiche Erfahrungen. Gleiche Meinung.

[@anyaplays7150]

Nein, es war nicht anders. Zum Glück ist dieser Unsinn jetzt Geschichte. Daily ist nicht mehr. Waren auch nicht 15 Minuten, sondern irgendwann auch mal 45 Min.

[@Rockodona]

Den Nagel aufn Kopf getroffen

[@rniestroj]

Bin da nicht bei Dir. Ich finde das Daily wo man aufs Board schaut und kurz durch die Tickets gut, informativ und geordnet. Das Daily mit der 3-Fragen Formel nenne ich das "Personen-abklappern Daily" und das gefällt mir nicht. Aber wenn es jemanden im Team (PO) gibt der diese Informationen bündeln kann dann ist es OK. Das schlimmste Daily das ich erlebt habe war das "Hat-Jemand-Was Daily". Die Stille in diesem Daily war fürchterlich. Mit dem Team Chat als alternative ja - das gibt und benutzt man ja sowieso. Dem Satz: "Schau doch ins Board, da ist der aktuelle Stand" stimme ich überhaupt nicht zu, weil meistens die Leute die Tickets nicht aktuell pflegen. Deshalb ist das Status-Meeting-Daily für mich ok.

[@M.B-z8d]

Wieso bist du "im mühsam erarbeiteten Tunnel", wenn das daily stattfindet? Das Daily findet immer zur gleichen Zeit statt, um genau das zu verhindern.

[@KD2139-b]

Ohne Daily, ohne mich. Wir arbeiten remote und asynchron - das Daily ist bei uns ein halbwegs informatives Kaffeekränzchen geworden und ich halte das Daily immer für relativ sinnig fürs Projekt - und die Zeit, die nach der Klärung bleibt, nutzen wir für den privaten Austausch. Das, was man früher bei der Zigarettenpause oder in der Kaffeeküche bequatscht hat, ist heute nicht mehr vorhanden. Den AG und das Projekt wird man aber nicht davon überzeugen, dass man sonst auch 15-30 Minuten des Tages im sozialen Austausch war und Remotearbeitende einen erweiterten Bedarf an sozialer Interaktion haben. Also missbraucht man das System und alle sind happy, zugleich hat man aber immer einen Blocker für Themen, wo eine Einschätzung eines erweiterten Kreises wichtig ist. Es mag immer den einen geben, der sich an den Standups (plus) stört - aber den brauche ich, zumindest in meinem Team, ohnehin nicht. Für Einzelgänger gibt es bestimmt schöne Soloprojekte.

[@ChristianSchroeder-uf3uh]

Wir arbeiten sehr remote und für mich ist das daily in erster Linie dazu da ein Team Gefühl herzustellen. Daher ist auch der nicht Sprint relevante teil, (wir nennen es Post scrum) fast wichtiger.

[@Snapdragon0593]

Leider ist die Basis der Kritik schon falsch! Laut SCRUM-Guide ist das Daily nämlich ein Meeting für die Developer und eben nicht für das SCRUM-Team! Der Guide schliesst also explizit PO und SCRUM-Master aus vom Daily, um eben ein solches Reporting zu verhindern! Dass das natürlich in der Realität wieder anders gelebt wird, ist ein anderes Thema. Aber der Guide möchte es definitiv nicht!

[@M.B-z8d]

Der scrum guide spricht davon dass das daily scrum ein meeting für die Developer ist, schließt aber po und scrum master keineswegs explizit aus: "If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."

[@Snapdragon0593]

@@M.B-z8d Korrekt, wenn sie als Developer fungieren, dann dürfen sie mit ins Daily. Aber das tun PO und SCRUM Master eher selten. Erst recht nicht in den Szenarien wo es in einem "Reporting ans Management" endet, wie hier kritisiert worden ist.

[@M.B-z8d]

"eher selten" ist immer schwierig. Der po wirkt selbstverständlich an den items im sprintbacklog mit. Ständig. Geht ja sonst auch gar nicht, dass die items so komplett spezifiziert sind dass während des sprints keine Absprachen mit po notwendig sind glaubt doch eh keiner

[@Snapdragon0593]

@@M.B-z8d Es geht darum, dass der PO aktiv Items abarbeitet. Für Abstimmungen zur Spezifikation, etc. gibt es gesonderte Termine. Das sind keine Themen fürs Daily!

[@M.B-z8d]

Du hast am anfang von der Teilnahme geschrieben. Natürlich dürfen po und scrum master teilnehmen. Im daily wird auch nicht uber Spezifikationen oder details diskutiert, sondern evtl. Probleme werden genannt und man verabredet sich fur weitere Gespräche. Das ist extrem wichtig für den PO

[@jorgw.6151]

15 min. für 8 Leute sind dann jeden Tag 2 Stunden verschenkte Zeit. Grauenhaft.

[@deleonio]

Hi, ich verstehe die konkrete Kritik am Daily nicht. Ein Daily dauert immer nur so lange wie nötig. Eine asynchrone Kommunikation im Team gehört mehr zu einer gesunden allgemeinen Teamkommunikation und wird meines Erachtens in Deinem Video zum kritisieren des Dailies herangezogen. Schade.

[@moccamixer]

Mich motiviert es ab und zu gas zu geben. Manche brauchen das eben 🤣

[@DerTim]

Klingt sehr egoistisch so viel Geld für ein paar Menschen auszugeben 🤔

[@Marcel-dr5pb]

the native rant

[@Daniel-c8y5r]

Software entwickeln ist einfach sch....se, egal ob mit oder ohne Scrum.

[@modparlor947]

Nach meiner Auffassung verstehst Du Dailies (komplett) falsch. Dailies sind dazu da, die soziale Interaktion sowie das gemeinsame Besitztum des Projekts ("Ownership") zu stützen. Du machst auch meiner Einschätzung nach einen signifikanten Fehler: ASAP. ASAP ist scheiße. Genau um ASAP abzuschaffen wurde das Daily erfunden. Geile Neuigkeiten? Nicht jetzt, bau grad am neuen Aktive Record für diesen Sprint, erzähl es _allen_ morgen im Daily und wir können uns alle gemeinsam freuen. Dafür ist das Daily gedacht. PO braucht schnell ein Dokument mit Technobabble um unsere neue Resource, die er besorgen soll zu rechtfertigen? Nicht jetzt, muss gerade die Message Queue auf Kette bringen. Wann? Genau: Morgen im Daily, frischer interner Task, gleich ins aktuelle Backlog und gleich mit Kollege Progger verfasst und rausgeschickt. Zwei können sich nicht über ein Build-Detail einigen und brauchen Feedback/Input/Vorschläge von anderen? Morgen im Daily klären. Dauert länger? Frischer Task für alle Kernbeteiligten, gleich ins aktuelle Sprintlog und rann an den Speck. Dailies sind präzise für die Dinge vorgesehen, die Du mit ASAP abfrühstücken willst. Großer Fehler IMHO! Auch ist die Timebox kein maximales muss! PO ist noch knietief im Politprozess und hat noch 5 Anrufe zu erledigen? "Bin noch dran, muss noch 5 Anrufe erledigen". Next. Ein Daily kann und sollte auch nach 90 Sekunden vorbei sein, wenn's nix neues oder wichtiges gibt. Das sollte nicht zu häufig passieren, dann drehen wahrscheinlich alle nur Däumchen oder machen Goldplating (meistens ist dann die Sprintlänge zu lang), but you get the picture. Dailies heißen Dailies weil sie täglich stattfinden. Der Arsch kommt weg von der Tastatur und vom Smartphone und wir treffen uns IRL um unser gemeinsames Baby zu besprechen und die "Ownership" des Projektes im gesamten Team lebendig zu halten. Alle gemeinsam, und auf dem kurzen Dienstweg nur dann, wenn wir alle gemeinsam entschieden haben, dass Mandy und Peter ihre Buildkollision heute erstmal zu zweit klären um ggf. morgen mit frischen Fragen oder Themen wieder anzukommen. Das ist nämlich kein Problem, wir haben nämlich ein Meeting dafür. Es heißt Daily. Wenn "Heute mal kein Daily" zuhäufig passiert, ist das ein schlechtes Zeichen. Dann haben wir kein gemeinsames Projekt und das ganze Scrum/Kanban/Whatever gemache ist hyperfluid und sinnfrei. Das ist dann ein Thema, was mit einem konkrete Projektteam eigentlich nichts mehr zu tun hat.