When daily scrums are lowering team ...

Einführende Videos über Scrum gibt es viele. Dieses hier zählt definitiv zu den Besseren. Gerade mal acht Minuten braucht Hamid Shojaee um seinen Zusehern viele Kernelemente von Scrum gespickt mit einigen persönlichen Erfahrungen zu vermitteln.



Klar, so manches Scrum -Artifakt oder -Meeting kommt in einem 8minütigen-Crash-Course zwangsläufig etwas zu kurz, aber dennoch ein gutes Video. Bemerkenswert finde ich neben der Gleichsetzung von ScrumMastern und Projektmanagern vorallem seine Einstellung zu Daily Scrums:

"The idea behind a standing meeting is that if everyone is standing nobody will waste time and therefore meeting will be short. And by meeting daily you can feel confident that everyone is on top of their tasks. The daily scrum is a great idea and especially useful in less experienced teams but I wouldn't call it a core or essential part of scrum. Insisting on these meetings in an already efficient and experienced team, especially teams that work in close proximity with one another could actually backfire by lowering team morality. Keep that in mind when deciding on having daily scrums." -- Hamid Shojaee über Daily Scrum

Heißt das also "Erfahrenes eingespieltes Team + aufrechter Kommunikationsfluss innerhalb des Teams" == "Daily Scrum kontraproduktiv"?

Auf keinen Fall! Schließt dieser aufrechte Kommunikationsfluss auch den Product Owner und vor allem auch den Scrum Master mit ein? für beide ist das Daily Scrum von wesentlicher Bedeutung. für den SM ist es ein Kanal um Impediments klar aufgezeigt zu bekommen, die zuvor vielleicht einem einzelnen Teammitglied aber nicht der ganze Gruppe bewusst waren. Blockaden die vielleicht bisher einfach nie angesprochen wurden. Außerdem ist das Daily Scrum nicht nur für das Team da. Es bietet auch Außenstehenden – allen Interessierten, wie etwa Marketing, Geschäftsführung, Kunden, potentiellen Nutzern... - eine Möglichkeit in ein Team und in ein Projekt hinein zu sehen.

"It's the meeting to end all meetings." -- Jonathan Rasmusson

Vor allem aber sollte das Daily Scrum natürlich seinen Teammitgliedern (und dem Projekt!) dienen. Es sollte Teil einer gefestigten Routine sein, die den (Tages-)Rhythmus vorgibt. Es ist mehr als ein Synchronisationsmeeting um sich über den Stand der Dinge zu informieren, es ist vor allem auch eine Gelegenheit ein Team noch enger zusammen zu schweißen und zu motivieren!

Aber es stimmt, einerseits sind auch erfahrene eingeschworene Teams die seit langem zusammen arbeiten, co-located sind, sich permanent austauschen und mit Scrum beginnen nicht vor schlechten Meetings sicher. Anderseits kann bei agilen Teams die tägliche taktische Planungskomponente (wer übernimmt welche Aufgaben?) mit der Zeit an Reiz verlieren kann. Oftmals begleitet von zusätzlichen Lästigkeiten, wie z.B. dass sich das Meeting verzögert, weil immer irgendjemand noch schnell irgendetwas fertig machen möchte. "Einen Moment noch! Muss nur noch schnell diese eine E-Mail fertig schreiben, dieses eine Telefonat führen, den Server neustarten, den Buildprozess anstoßen... (und dann unvorbereitet zum Daily Scrum)"

In solchen Fällen könnte ein Funkwecker im Teamraum helfen oder das automatisierte Abspielen eines bestimmten Songs, wie z.B. die Anfangssequenz von The Final Countdown von Europe oder irgendeinem anderen Song aus Rocky.

Aber klar, wenn jemand gerade im Flow ist, ist jede Unterbrechung schlecht.

"The purpose is not to meet... it is to improve." -- Joe Ely

Ein weiterer positiver Aspekt von Daily Scrums: Wenn man als Entwickler morgens beim Daily Scrum seinem Team - quasi öffentlich - erklärt, dass man die Funktion »Speichern« bis zum nächsten Daily Scrum liefern wird, dann erhöht das auch die Chance, dass das Feature tatsächlich geliefert wird (=commitment/forecast to each other). Jeder Mensch möchte stolz auf sich sein, möchte von anderen wertgeschätzt werden und niemand möchte seine Kollegen enttäuschen. Dieses Verhalten und der Wunsch etwas Qualitatives zu liefern ist meiner Erfahrung nach unter Softwareentwicklern besonders ausgeprägt.

Abschließend ein Tipp aus Jason Yips Artikel: It's Not Just Standing Up: Patterns for Daily Standup Meetings

"Instead of thinking of the daily stand-up as a ritual for the people, think of it as a ritual where the Work Items Attend (e.g., User Stories in an Agile context) and the people attend only to speak for the work items... since obviously the work items can't actually talk." -- Jason Yip