Scrum-Leitfaden | 35. Tägliches Gedränge

Veröffentlicht: 2022-07-08

Das Daily Scrum dauert nicht länger als fünfzehn Minuten und findet immer am selben Ort und zur gleichen Zeit statt, um unnötige Komplexität zu reduzieren. An ihm nehmen alle Entwickler teil, die gemeinsam am Produkt arbeiten, und optional der Scrum Master. Der Hauptzweck dieses Scrum-Events besteht darin, die Aufgaben zu planen, auf die sie sich für den Tag konzentrieren werden.

Daily Scrum – Inhaltsverzeichnis:

  1. Einführung
  2. Die Daily-Scrum-Formel
  3. Probleme mit Daily Scrum und der 5W-Methode
  4. Unterstützende Fragen
  5. 5 Warum
  6. Zusammenfassung

Einführung

Daily Scrum ist das kürzeste und häufigste der Scrum Events, dessen Übersicht in einem separaten Artikel zu finden ist. Die Aufgabe der am Daily Scrum teilnehmenden Entwickler besteht darin, sich schnell Arbeitsziele für die nächsten 24 Stunden zu setzen. Auf diese Weise weiß jeder von ihnen, woran die anderen arbeiten und wie sie auf ein gemeinsames Sprint-Ziel hinarbeiten.

Die Daily-Scrum-Formel

Es gibt nicht die eine richtige Daily-Scrum-Formel. Jedes Entwicklungsteam entwickelt ein Meeting-Format, das für es funktioniert. Es gibt jedoch einen allgemeinen Rahmen , der die Durchführung erleichtert.

Ein gut durchgeführtes Daily Scrum sollte es jedem Teilnehmer ermöglichen, zwei Fragen zu beantworten:

  • Was ist die wichtigste Aufgabe, die ich heute erledigen werde?
  • Was sind die Hindernisse bei der Erfüllung dieser Aufgabe?

Sie direkt zu fragen, ist jedoch keine zwingende Formel. Dies sind Beispielfragen, die die Achse des Meetings definieren. Daily Scrum soll die Kommunikation im Entwicklungsteam verbessern, Aufgaben priorisieren und das Risiko von Engpässen reduzieren.

Das Daily Scrum ist ein Event, das dem Daily Standup in anderen agilen Methoden entspricht. Und es läuft oft sehr ähnlich ab – obwohl der offizielle Scrum Guide von Entwicklern nicht verlangt, während dieses kurzen Events zu stehen. Sehr oft stehen die Teilnehmer einfach nur da, während sie sich in einer informellen Gruppe unterhalten.

Auch wenn 15 Minuten pro Tag für die Besprechung der täglichen Aufgaben viel zu sein scheinen, zeigt die Praxis, dass ein solches Meeting am besten für die Effektivität des Entwicklungsteams ist. Mit häufigen und regelmäßigen Updates zu Zielen und Verpflichtungen konzentrieren sich alle Entwickler auf vorrangige Aufgaben und geben dem reibungslosen Teamfortschritt Vorrang vor individuellen Ergebnissen.

Daily Scrum

Probleme mit Daily Scrum und der 5W-Methode

Eines der Probleme mit Daily Scrum ist, dass Entwickler die Besprechungszeit in die Länge ziehen. Wenn dies der Fall ist, ist es eine gute Idee, eine Richtlinie einzuführen, bei der problematische Themen, die nicht im Mittelpunkt des Daily Scrum stehen, aber für das Team wichtig sind, auf einer Tafel – entweder physisch oder virtuell – niedergeschrieben werden. Auf diese Weise wird es möglich sein, auf die Probleme zurückzukommen, die während der informellen Diskussionen im Laufe des Tages noch zu diskutieren waren. Und bei Bedarf auch während der Sprint-Retrospektive, die wir in einem separaten Artikel näher beschreiben.

Ein weiteres Problem, das bei Daily Scrums häufig auftritt, besteht darin , sie in Meetings zu verwandeln, um die Arbeit des Vortages zusammenzufassen. Entwickler konzentrieren sich dann darauf, die bereits erzielten Ergebnisse zu diskutieren. Dies ist keine gute Praxis. Zugegebenermaßen ist die aktuelle Orientierung der Entwickler zum Stand der Arbeit, die zum Sprint-Ziel führt, sehr wichtig. Allerdings ist es nicht effizienzfördernd, das Daily Scrum bereits erledigten Aufgaben zu widmen.

Unterstützende Fragen

Wenn das Team nicht vom Daily Scrum profitiert, kann der Scrum Master den Entwicklern helfen, Probleme zu identifizieren, indem er das Meeting beobachtet, um Antworten auf die folgenden Fragen zu erhalten:

Daily Scrum

5 Warum

Nach der anfänglichen Identifizierung des Problems kann eine effektive Technik zur Bestimmung der Ursache des Problems die 5-Why-Methode sein, die von Sakichi Toyoda auch 5-Why oder 5W genannt wird. Es geht darum, mehrere „Warum?“ zu fragen. Fragen hintereinander. Dies ermöglicht es, die tiefere Ursache des Problems zu diagnostizieren und es somit einfacher zu lösen.

Nehmen wir zum Beispiel den letzten Punkt in der Tabelle: Das Problem entsteht im Bereich des Engagements für die Problemlösung durch das Entwicklungsteam. Die fünf Fragen könnten wie folgt aussehen:

1 x WARUM?

F: Warum bieten Entwickler keine verschiedenen Möglichkeiten an, um auftretende Probleme zu lösen?

A: Weil Entwickler Harry immer der Erste ist, der eine Lösung vorschlägt.

2 x WARUM?

F: Warum ist Entwickler Harry immer der Erste, der eine Lösung vorschlägt?

A: Weil sonst niemand spricht.

3 x WARUM?

F: Warum meldet sich niemand?

A: Weil andere Entwickler keine Lust haben, nach besseren Lösungen zu suchen.

4 x WARUM?

F: Warum haben andere Entwickler keine Lust, nach besseren Lösungen zu suchen?

A: Weil das Finden von Lösungen Konzentration erfordert und es einfacher ist, Harrys Lösung als gut genug zu betrachten.

5 x WARUM?

F: Warum hielten sie Harrys Lösung für gut genug?

A: Da sie für das Vorschlagen von Alternativen nicht belohnt werden, haben sie zu Beginn des Meetings ihre Pläne für heute besprochen und denken über den Einstieg nach.

In diesem Fall kann das Problem des fehlenden Engagements zur Lösung von Problemen gelöst werden, indem die Reihenfolge des Daily Scrum geändert und mit diesem Problem begonnen wird. Oder ein System entwickeln, um die beste Lösung zu belohnen, zum Beispiel die Einführung einer symbolischen Belohnung für den Autor der meisten vom Team in einem bestimmten Sprint akzeptierten Lösungen.

Zusammenfassung

Daily Scrum ist ein wichtiger Bestandteil der täglichen Arbeit des Entwicklungsteams. Allerdings muss jedes Team für sich die optimale Formel für dieses Treffen erarbeiten. Ein gut durchgeführtes Daily Scrum ermöglicht die fortlaufende Festlegung von Unterzielen, um das Sprint-Ziel zu erreichen. Es ermöglicht auch, Kommunikationsprobleme schnell zu diagnostizieren und die Zusammenarbeit zwischen Entwicklern zu verbessern.

Wenn Ihnen unsere Inhalte gefallen, werden Sie Teil unserer fleißigen Bienen-Community auf Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Scrum Guide | 35. Daily Scrum caroline becker avatar 1background

Autorin: Caroline Becker

Als Projektmanagerin ist Caroline Expertin darin, neue Methoden zu finden, um die besten Arbeitsabläufe zu gestalten und Prozesse zu optimieren. Ihre organisatorischen Fähigkeiten und ihre Fähigkeit, unter Zeitdruck zu arbeiten, machen sie zur besten Person, um komplizierte Projekte in die Realität umzusetzen.

Scrum-Leitfaden:

  1. Glossar der Grundbegriffe, Rollen und Begriffe
  2. Was ist Scrum?
  3. Scrum-Werte
  4. Wie implementieren Sie Scrum in Ihrem Unternehmen?
  5. Scrum Team – was ist das und wie funktioniert es?
  6. Wer ist ein Product Owner?
  7. Die häufigsten Fehler des Product Owners
  8. Wer ist der Scrum-Master?
  9. Eigenschaften eines guten Scrum Masters
  10. Die häufigsten Fehler des Scrum Masters
  11. Welche Statistiken und Metriken sollte der Scrum Master verfolgen?
  12. Zusammenarbeit zwischen Product Owner und Scrum Master
  13. Entwicklungsteam in Scrum
  14. Die häufigsten Fehler von Entwicklern
  15. Scrum-Artefakte
  16. Scrum skalieren
  17. Sprint-Rückstand
  18. Was ist das Product Backlog?
  19. Was sind User Stories?
  20. Erstellen Sie die beste User Story mit INVEST
  21. Die häufigsten Fehler in User Storys
  22. Akzeptanzkriterien für User Storys
  23. Schätzung und Story Points in Scrum
  24. Planungspoker
  25. Team-Schätzspiel
  26. Inkrement definieren
  27. Scrum-Ereignisse
  28. Was ist Sprint in Scrum?
  29. Verpflichtungen des Scrum-Teams – Produktziel, Sprintziel und Abschlussdefinition
  30. Was ist ein Burndown-Diagramm?
  31. Wie erstellt und interpretiert man ein Burndown-Diagramm?
  32. Vor- und Nachteile des Burndown-Charts
  33. Kanban-Boards in Scrum und Scrumban
  34. Velocity in Scrum - Schnelligkeit des Entwicklungsteams
  35. Tägliches Scrum
  36. Sprint-Planung
  37. Sprint-Review
  38. Was ist eine Sprint-Retrospektive?
  39. Häufige Fehler während einer Sprint-Retrospektive
  40. Pflege des Produkt-Backlogs