Das StandUp-Meeting oder, wie es im Scrum heißt, das Daily Scrum, ist meiner Meinung nach das wichtigste Meeting im agilen Umfeld. In unserem Unternehmen wurde dieses 15 minütigen Meetings von den Entwicklern bereits eingeführt, lange bevor die Begriffe Agile und Scrum im Management angekommen sind.

Auch in anderen Unternehmen wurden StandUps anfangs von den Entwickler-Teams als große Bereicherung im Software-Prozess angesehen, jedoch empfinden viele sie mitlerweile als überflüssiges und nerviges Übel, das den Programmierer nur aus dem Arbeitsfluss reißt und wenig Mehrwert bietet.

Daily Scrum als Entwickler-Meeting

Um den Sinn und Zweck des StandUps bzw. Daily Scrum zu verstehen, hier einmal eine Definition aus dem Scrum Guide:

Das Daily Scrum ist eine Time Box von 15 Minuten, innerhalb derer das Entwicklungsteam seine Aktivitäten synchronisiert und an der Planung für die nächsten 24 Stunden arbeitet.

Bemerkenswert an dieser Definition ist, dass sie das Daily Scrum als Entwickler-Meeting begreift. Entwickler treffen sich 15 Minuten, um sich zu synchronisieren.

Ziel des Meetings

Ziel des Meetings muss sein, dass jeder im Entwickler-Team weiß, woran das Team gerade arbeitet, welche Probleme in den nächsten Stunden anstehen und wie das Team diese Probleme löst.

Anti-Pattern: Status-Meeting

Bei vielen StandUps, die ich in den letzten Jahren mitgemacht habe, stand nicht das Entwickler-Team sondern ein Projektmanager, Product Owner oder zumindest ein Scrum Master im Mittelpunkt. Die Folge davon ist, dass bei solchen Daily Scrums die Synchronisierung des Teams nur noch eine untergeordnete Rolle spielt und die ganze Veranstaltung zu einem reinen Status-Meeting verkommt. Erkennen kann man eine solche Entwicklung gut, indem man beobachtet wie die Entwickler beim Sprechen ihren Blick immer auf den anwesenden Projektleiter richten.

Diese Entwicklung ist der Tod des StandUps. Zwar hat ein Projektleiter nach einem solchen Meeting im Besten Fall einen recht guten Überblick über den Projektstatus, jedoch muss er dafür einen sehr hohen Preis zahlen:

Die selbstorganisierte Synchronisierung des Teams findet bei solch einem Meeting so gut wie überhaupt nicht mehr statt. Jeder betet nur die Tasks herunter, die er am Vortag abgearbeitet hat und committet sich auf eine bestimmte Anzahl an Tickets. Kollaboratives Arbeiten am Projektziel? Fehlanzeige!

Zudem gewinnt das Meeting nicht unbedingt im Preis-/Leistungs-Verhältnis, wenn es als Status-Meeting missbraucht wird. Einmal abgesehen davon, dass StandUps, bei denen Projektleiter teilnehmen in der Regel 30 statt 15 Minuten dauern, ist es deutlich kostengünstiger für einen Projektleiter, wenn er nach dem StandUp den Projektstatus mit einem Entwickler bespricht, anstatt mit dem ganzen Team. Und manchmal reicht ja auch schon ein Blick auf das Burndown-Chart.

Anti-Pattern: Ticket-Assignment

Das zweite große Anti-Pattern bezüglich StandUps ist, das Meeting als reinen Ticket-Basar abzuhalten. Hierbei betet jeder die Ticket-Nummern der Tasks herunter, die er am Vortag geschafft hat und auf Tickets die er heute bearbeiten will, wird sein Avatar geklebt.

Wenn man nach einem solchen Meeting einen der teilnehmenden Entwickler fragt, was denn nun konkret von den anderen Teammitgliedern am Vortag geleistet wurde, schaut man meist in leere Augen. Gerade bei Teams die an mehreren Projekten arbeiten fällt auf, dass viele während der Redezeit eines anderen Entwicklers einfach abschalten.

Abgesehen davon ist der Sinn des Ticket-Assignments nicht wirklich nachzuvollziehen. Man kann wohl von jedem erwarten, dass er sich sein im StandUp vorgenommenes Tagesziel für die nächsten 8 Stunden merken kann. Im Gegenteil hat das Assignment auch Nachteile: Ein Ticket, welches einer Person zugewiesen wurde, wird nur selten von einem anderen Team-Mitglied bearbeitet. Somit werden Tickets reserviert und es kann zu einem vermeidbaren Ticket-Stau kommen.

Zudem kommt es in selbstorganisierten Teams nicht selten vor, dass sich im Laufe des Tages ganz neue Baustellen auftun. Soll man nun seinem Teamkollegen die Hilfe verweihren, auch wenn der Task an dem er sitzt viel relevanter für das erreichen des Sprintziel ist, nur weil man sich morgens ein bestimmtes Kontingent an Tickets zugewiesen hat?

Fazit

Um StandUps nicht zu Status-Meetings verkommen zu lassen, sollten Projektleiter möglichst nicht aktiv am Meeting teilnehmen. Es gibt deutlich bessere Möglichkeiten sich über den Status zu informieren, sei es durch den Blick auf das Burndown oder ein gesondertes Gespräch im kleineren Kreis. Am sinnvollsten ist es jedoch, wenn das selbstorganisierte Team von sich aus erkennt, wenn das Sprintziel gefährdet ist und in einem solchen Fall den Projektleiter um Hilfe bittet.

Sinnvoller als Ticket-Assignment ist es, kollaborativ die geleistete Arbeit des Vortags zu besprechen und zu bewerten und das Ziel des nächsten Tages gemeinsam zu definieren und gemeinsam mögliche Hindernisse zu erkennen.

Ereichen kann man dies zum Beispiel, indem ein jeden Tag ein anderer Entwickler die gesamte durch das Teams geleistete Arbeit des Vortages zusammenfasst. Hierbei wird er von den weiteren Teammitgliedern unterstützt. Anschließend wird ein gemeinsames Tagesziel definiert, wobei jeder Teilnehmer erklärt, wie er persönlich das Team unterstützen möchte, um dieses Tagesziel zu erreichen.