Ist das Daily Standup für Teammitglieder zwingend?

Daily StandupVon Zeit zu Zeit erhalte ich Anfragen von Lesern, zu denen ich natürlich sehr gerne auch Rückmeldung gebe. Im aktuellen Fall handelt es ich um eine Frage, die uns vor längerer Zeit auch einmal bewegt hat: „Ist das Daily Standup für Teammitglieder zwingend?“
Gerne führe ich meine Gedanken hierzu aus, freue mich aber auch über Ergänzungen anderer Leser über die Kommentarfunktion.

Was ist ein Daily Standup?

Um alle Leser abzuholen, möchte ich noch einmal vorstellen, worum es sich bei Daily Standups eigentlich handelt. Daily Standups sind tägliche Kurzbesprechungen des Projektteams und einer der Grundbestandteile agiler Softwareentwicklung. In Scrum wird hierfür die Bezeichnung „daily scrum“ verwendet. Es ist ein fest verankertes Element in Scrum. Aber auch in Teams, die mit Kanban arbeiten, werden tägliche Standup-Meetings häufig eingesetzt.

Als Grundregel kann angesehen werden, dass dieses Meeting maximal 15 Minuten dauern sollte. Jeden Tag, zur selben Uhrzeit am gleichen Ort. In dieser Zeit beantworten alle Teilnehmer die folgenden Fragen:

  • Was wurde seit dem letzten Standup-Meeting gemacht?
  • Was wird bis zum nächsten Standup-Meeting erledigt?
  • Gibt es Hindernisse, Herausforderungen oder Optimierungsbedarfe, die angegangen werden sollten?

Optimalerweise findet dies an einem Taskboard statt, wie in obigem Bild dargestellt, damit alle auch direkt sehen können, von welcher Aufgabe der Kollege gerade spricht. Gemeinsam wird dann dieses Taskboard auch im Standup-Meeting aktualisiert, etwa erledigte Aufgaben verschoben.

Ist ein Teilnahmezwang für Daily Standups sinnvoll?

In der weniger agilen Praxis werden die Standup-Meetings häufig in Frage gestellt. So sind sowohl bei den Projektteams selbst als auch beim Management der Sinn und Nutzen nicht selten umstritten.

Zunächst einmal ist es meines Erachtens sinnvoll, den täglichen Einsatzbesprechungen eine ernsthafte Chance zu geben. Hat das Team also noch gar keine Erfahrung damit gemacht, wäre es ein guter Schritt, diese für einen längeren Zeitraum, zum Beispiel für 4 oder 6 Wochen oder bei Scrum-Teams für 2-3 Sprints einfach einmal auszuprobieren. Einen Zwang würde ich für nachteilig halten, da hier ganz klar mit Gegenwehr gerechnet werden muss. Vielmehr sollte das Team gemeinsam einen solchen Test-Zeitraum beschließen. Wenn dann negative, schlecht begründete Kritik auftaucht, kann derjenige darauf verwiesen werden, dass sich gemeinsam für eine Testphase entschieden wurde, die erst einmal abgewartet werden sollte. Wenn ernsthafte Verbesserungsvorschläge vorgetragen werden kann geschaut werden, dass diese möglichst schon frühzeitig mit in die Standups eingebracht werden.

Wir haben die Erfahrung gemacht, dass Standup-Meetings von Teammitgliedern insbesondere in den folgenden Fällen kritisiert werden:

  • Die Meetings ziehen sich ewig hin und kommen nicht auf den Punkt. Dann sollte darauf geachtet werden, dass die Timebox eingehalten wird und Themen, die nur einen kleinen Teil der Gruppe betreffen erst im Anschluss an das Daily Standup besprochen werden.
  • Es wird gar nicht zusammen gearbeitet. Wenn jeder eh an seiner eigenen Baustelle arbeitet, dann erscheint der gegenseitige Austausch natürlich überflüssig. In diesen Fällen steht das Team vor einer größeren Herausforderung und sollte sich eventuell einmal damit beschäftigen, wie Teamwork in der agilen Softwareentwicklung verstanden und angewendet wird.
  • Es fehlt eine Moderation. Bei Scrum-Teams macht dies häufig der Scrum-Master, die Moderation kann aber auch abwechselnd von Teammitgliedern übernommen werden. Es sollte aber immer klar sein, wer gerade Moderator ist und dieser sollte z.B. darauf achten, dass die Redeanteile möglichst ausgeglichen sind. Nur wenn auch alle zu Wort kommen, macht es für sie auch Sinn, sich an dem Meeting zu beteiligen.
  • Es fehlt eine feste Zeit und ein fester Ort. Wenn die Meetings nicht allen Teammitgliedern in Fleisch und Blut übergehen und einen festen Platz im Kalender aller Teammitglieder haben, geht unnötig viel Zeit dafür verloren zu klären, warum Kollege A und Kollegin B gerade noch nicht anwesend sind. Manche Teams arbeiten auch mit „Strafen“, falls jemand unentschuldigt fehlt oder zu spät kommt. Dies können z.B. 10 Cent für das Team-Sparschwein sein, die dann nach etwas sammeln in einen Kuchen für das Team investiert werden.
  • Probleme werden nicht angegangen. Wenn immer wieder die gleichen Herausforderungen auftreten oder ein Kollege im Standup jeden Tag das gleiche erzählt, da er offensichtlich ein Problem mit einer Aufgabe hat, sollten beim Team die Alarmglocken angehen und für eine dauerhafte Lösung gesorgt werden. Standup-Meetings sind eine gute Möglichkeit, kontinuierliche Verbesserungsprozesse anzustoßen.

Nach dem wir nun ein paar Jahre Erfahrung mit Daily Standups haben, kann ich mir kaum noch vorstellen, wie ein Team, dass sehr eng zusammen arbeitet, ohne diese kurzen Einsatzbesprechungen effektiv und effizient zusammen arbeiten kann.

Weitere Informationen zu Daily Standups:

Foto: tomnatt

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Werbeanzeigen

Sprint-Review: Konstruktives Feedback geben, wenn es einmal schlecht läuft

Review / Demo / Sprint-Review / Scrum ReviewDer Sprint neigt sich dem Ende zu und das Review-Meeting, welches im Rahmen jedes Scrum-Sprints zur Präsentation der Arbeitsergebnisse durchgeführt wird, steht an. Spätestens jetzt zeigt sich, was das Scrum-Team in den letzten Wochen geleistet hat und erreichen konnte. Der Product Owner ist gefordert, „seinem“ Team Feedback dazu zu geben, wie er mit den Arbeitsergebnissen zufrieden ist.

Doch wie sollte er damit umgehen, wenn es einmal wirklich schlecht gelaufen ist und das Team bei weitem nicht die Fortschritte erreichen konnte, die gemeinsam geplant wurden?

Dem Team zuhören

Zunächst einmal ist es wichtig, dem Team die Chance zu geben, aufgetretene Hindernisse im Sprint-Verlauf darzulegen. Womöglich waren sie durch größere Ereignisse im Live-Betrieb von der Arbeit am Sprint-Ziel verhindert, haben aber ihr bestes gegeben, das System am laufen zu halten. Dies kann z.B. der Fall sein, wenn ein ungewöhnlich starkes Nutzerwachstum aufgetreten ist, dass sich nicht vorhersehen ließ. Dadurch ändert sich nicht die Situation, dass das Sprintziel nicht erreicht wurde, es ist aber doch ein Unterschied, ob das Team alles gegeben hat und es trotzdem nicht geklappt hat, oder ob die Verfehlung des gemeinsamen Ziels andere Gründe hatte. Womöglich teilt das Team dabei auch wichtige Informationen mit, die dem Product Owner und dem ScrumMaster die Möglichkeit bieten, das Team bei der Erreichung zukünftiger Zielsetzungen zu unterstützen. Damit es dazu kommen kann, muss dem Team aber die Möglichkeit gegeben werden, eine Selbsteinschätzung zu geben.

Die eigene Perspektive erklären

Das Feedback des Product Owners sollte klar und verständlich zum Ausdruck kommen. Das sollte allerdings jederzeit sachlich und konstruktiv erfolgen. Wurde nicht nach den vereinbarten Prioritäten gearbeitet, kann noch einmal herausgestellt werden, warum sie so festgelegt wurden. Wurde einem Stakeholder gegenüber in Abstimmung mit dem Team eine Zusage gemacht, die nun nicht eingehalten werden kann, sollte das auch noch einmal betont werden. Die Konsequenzen des schlechten Sprintverlaufs sollten dargestellt werden. Da der Product Owner die wirtschaftliche Verantwortung für das Projekt trägt, sollte er gerade auch die betriebswirtschaftliche Sicht mit einbringen und die Interessen der Stakeholder vertreten.

Das Ziel nicht aus den Augen verlieren

Ein schlechter Sprint tut weh. Er tut dem Product Owner weh, der die wirtschaftliche Verantwortung für das Projekt trägt. Er tut dem Team weh, das seine selbst gesteckten Ziele nicht erreicht hat. Und auch dem ScrumMaster tut er weh, da ihm eine Menge Arbeit bei der Aufarbeitung bevorsteht.
Aus dieser schmerzlichen Situation heraus sollte das Ziel des Product Owners nicht sein, dass das Team sich noch schlechter fühlt. I.d.R. können sich die Teams auch selbst gut einschätzen und sind selbst unzufrieden, wenn das Sprintziel nicht erreicht wurde. Dennoch sollte er klar darstellen, wie die Erwartungshaltung war und wie das gelieferte Ergebnis sich dazu verhält. Es kann auch anhand eines Release-Burndown-Chart ermittelt werden, wie die Auswirkungen auf den Releasetermin (wenn der Umfang fixiert, das Datum variabel) oder den Releaseumfang (wenn der Umfang variabel, das Datum fixiert ist).

Gemeinsam nach Lösungen suchen

In der Retrospektive besteht noch einmal ausführlich die Möglichkeit, den zurückliegenden Sprint aufzuarbeiten und Verbesserungsmaßnahmen zu erarbeiten. Persönlich habe ich gute Erfahrungen damit gemacht, als Product Owner bei den Retrospektiven des Teams dabei zu sein. Das machen wir allerdings nur, wenn das Team dem zustimmt. Denn für einen offenen Umgang mit Kritik ist eine situative Ermöglichung der Kritik erforderlich. Die Teammitglieder müssen das Gefühl haben, dass sie Fehler offen ansprechen dürfen. Das ist meist eine Frage des Vertrauens.

Fazit

Gerade ein schlechter Sprint zeigt, ob das Team wirklich ein Team ist. Der Product Owner sollte seine Erwartungen und die Erwartungen des Stakeholder klar vertreten. Vertrauen ist die Basis für ein erfolgreiches Team.

 

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Foto: psd

Die Bedeutung von Kritik in der Teamarbeit

Ein Team sollte auch offen miteinander kommunizierenIn der heutigen Arbeitswelt wird immer stärker auf Teamarbeit gesetzt. Umso wichtiger wird es auch, sich zu fragen, was ein gutes, starkes Team ausmacht. Zu einem starken Team gehört mehr, als nur gut zusammen zu arbeiten. Die volle Kraft kann ein Team erst dann entfalten, wenn es synergetisch zusammenarbeitet. Dies bedeutet, dass die Leistung des Teams größer und besser wird als die Summe der Leistungen der einzelnen Teammitglieder.

Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: