In den Daily Stand Ups bei Scrum werden üblicherweise von jedem Team-Mitglied die folgenden drei Fragen beantwortet: Was habe ich seit dem letzten Daily Stand Up gemacht? Was werde ich bis zum nächsten Daily Stand Up machen? Gibt es etwas, das mich zur Zeit bei meiner Arbeit behindert? Meiner Erfahrung nach sorgen diese drei Fragen zu unnötigen und zeitraubenden Ausführungen und Diskussionen.
Man kann die für das Daily Stand Up wichtigen Informationen fokussierter austauschen, wenn man die Fragen folgendermaßen formuliert:
- Was habe ich seit dem letzten Daily Stand Up fertig gestellt?
- Was werde ich bis zum nächsten Daily Stand Up fertig stellen?
- Was behindert mich bei meiner Arbeit?
So rückt das Ziel, möglichst immer etwas fertig zu stellen, ins Zentrum und die einzelnen Personen fokussieren sich darauf, anstatt ausführlich zu schildern, was sie alles gemacht haben. So fokussiert bleibt in der Regel Zeit, sich noch zwei weitere Fragen zu beantworten, um auch die kontinuierliche Verbesserung der Code-Qualität nicht aus den Augen zu verlieren.
- Welche Unschönheiten (im Code) oder fehlend Tests habe ich seit dem letzten Daily Stand Up entdeckt?
- Welche Optimierungen (im Code) habe ich seit dem letzten Daily Stand Up durchgeführt?
14 Comments
Leave a CommentDas Abschließen eines Arbeitspakets ist doch nicht die einzige Möglichkeit, um den Fortschritt an etwas auszudrücken. Die von Scrum vorgesehene Möglichkeit ist zum Beispiel den geschätzten Restaufwand zu aktualisieren (“As work is performed or completed, the estimated remaining work is updated”), aber wenn die Leute sowas sagen wie “Ich hab gestern an den Unittests für X gearbeitet, heute arbeite ich daran, dass die Tests grün werden” gibt das dem Entwicklungsteam (!) doch auch Aufschluss über den Fortschritt.
Zusätzlich ergeben sich Chancen, dass das Team Infos erhält, die sie bei einer vergleichsweise geschlossenen Formulierung (“Ich habe X abgeschlossen, heute arbeite ich an Y”) nicht erhalten. Was ja eigentlich im Sinne einer besseren Wissensverteilung im Team gewünscht ist. Nur Zettel am Board zu verschieben, würde ja bisschen die übergeordneten Ziele des Dailys verfehlen.
Was deine Frage zu meiner Interpretation deines neueren Artikels angeht: Ich nahm das deshalb an, weil du in deinem neueren Artikel wieder die ursprünglichen Formulierung aufgreifst und schriebst, dass mit diesen Fragen im Hinterkopf “über den aktuellen Stand der Aufgaben gesprochen” wird. Das beinhaltet für mich, dass man feststellen kann “Okay, ich hab hier und da dies und dies gemacht” und nicht gezwungen ist “Ich hab nichts abgeschlossen” zu antworten.
Zu wissen woran das Team arbeitet ist gut, zu wissen, welche Aufgaben abgeschlossen werden konnten, ist besser.
Welchen konkreten Wert erzeugt ein Unit Test, der noch nicht abschließend entwickelt wurde und noch nicht funktioniert?
Ziel ist es, die Aufgaben so runter zu brechen, dass z.B. der Unit Test innerhalb eines Tages abschließend entwickelt werden kann. Das ist ein viel höherer Wert, als sich auf Aussagen einzelner im Team verlassen zu müssen, zu wie viel Prozent eine Aufgabe fertig ist, die “heute nur noch abgeschlossen werden muss”. Da habe ich viel zu oft erlebt, dass das Pareto Prinzip zuschlägt und dass Dinge, die vermeintlich fast fertig sind, noch viele Tage bearbeitet werden mussten.
Die Aussage, dass man an etwas Arbeit, ist ein Status Bericht mit geringem Nutzen. Nur was fertig ist, hat die Chance wertvoll zu sein und mehr zu Nutzen, als nur Information zu liefern.
Ich stelle dir mal eine Gegenfrage: Welchem Zweck dient aus deiner Sicht das Daily? Und welchen Wert kann es für das Team generieren?
So wie du es beschreibst, klingt ein Arbeitstag wie ein Sprint im Sprint. Dabei dient das Daily offenbar nur dem einen Zweck: zu prüfen, dass das Team genügend Output produziert.
Das ist aber nicht Sinn der Sache.
Im Daily geht es um Synchronisation (!) innerhalb des Teams, also Kommunikation im besten Sinne, und die Betrachtung des Fortschritts ist nur ein Hilfsmittel dafür.
Der Zeitpunkt um Arbeiten abzuschließen ist das Ende des Sprints. Unter diesem Gesichtspunkt ist mir völlig unklar, welcher Wert darin besteht, eine Aufgabe so weit runter zu brechen, dass sie innerhalb eines Tages abgeschlossen werden kann. Erscheint mir ein bisschen zu sehr “Following a plan over responding to change” zu sein.
Kennst du diese Burndown Charts, die bis zum Ende des Sprints eine Linie bilden und dann schlagartig abfallen zum Sprint Ende? Wenn nicht Ziel ist, auch jeden Tag wertschöpfende Arbeit abzuschließen, passiert das.
Das Daily ist das Planungsmeeting für den Tag, dazu gehört Synchronisieren und Kommunikation immer mit dem Ziel, an dem Tag möglichst viel abschließend fertig zu stellen.
Bei uns nehmen die PO im Sprint ab und wir sehen täglich einen verlässlichen Fortschritt. Um das sicher zu stellen, ist das Daily wertvoll.
Wir nutzen das Daily auch, um über die Bearbeitung von Impediments zu sprechen, Ungeplantes im Tag einzuplanen oder in den nächsten Sprint zu verschieben und ähnliches. Am Ende des Dailys wissen die Kollegen, wer an was arbeitet mit dem Ziel es am Tag abzuschließen, sie wissen voneinander, wer bei was Hilfe braucht und was gemeinsam nötig ist, um das Sprintziel zu erreichen, weil für alle transparent ist auf täglicher Ebene, was schon fertig ist und was nicht.
Ok, wird für euch sicher alles seine Berechtigung haben. Ich kann natürlich aus meiner Perspektive eure Situation nicht beurteilen und will ich auch nicht.
Aber eins interessiert mich jetzt noch: Wenn du sagst, dass der PO im Sprint abnimmt, meinst du damit irgendwann im Sprint oder ist das auch an euer Daily gebunden?
Weil mehr als eine Abnahme innerhalb des Sprints, ist ja schon eine ziemliche Änderung der “Spielregeln”. Wenn das aber in einem Team notwendig wäre, also wenn der beschrieben Burndown-Chart-Verlauf wirklich regelmäßig vorkommt, könnte ich mir vorstellen, dass das nur ein Symptom für ein tieferliegendes Problem ist wie beispielsweise fehlendes Commitment.
Wieso ein häufigeres Ausliefern, also ein regelmäßiges und schnelles Liefern von Kundennutzen (häufiger als alle 1-4 Wochen), ein Symptom für ein tieferliegendes Problem sein soll, weil es irgendwelchen vermeintlichen Spielregeln nicht erfüllt, kann ich nicht nachvollziehen und halte ich auch für grundverkehrt.
Mir ist das Einhalten von Scrum (by the Book) nicht wichtig, es geht darum möglichst schnell Kundennutzen zu generieren. Alle zwei Wochen ist nicht häufig genug.
Und nein, die neuen Werte werden idealerweise direkt abgenommen, wenn sie fertig sind. Die Abstimmung, wann der PO abnimmt, findet im Daily statt und da gibt es auch die Info, wenn es final angenommen wurde.
Im Review wird das Ergebnis den Stakeholdern vorgestellt, die es vielleicht noch nicht gesehen haben, um weiteres Feedback abzuholen.
Die “Spielregel”, die ich meine (und weil ich von by the book auch nix halte, hab ich den Begriff in Anführungszeichen gesetzt habe), ist meiner Meinung nach noch wichtiger als Wert für den Kunden generieren: nachhaltiges Arbeiten (fürs Team).
Wenn ich aber den Fokus darauf lege, noch vor Ende des Sprints auszuliefern und sogar versuche, dies per Prozess zu erzwingen, ist das nichts Anderes als eine erhöhte Schrittgeschwindigkeit.
Und das hat für mich einfach nix mit Sustainable Pace zu tun.
Wer sagt denn, dass mit Prozess ein frühzeitiges Ausliefern erzwungen wird. Es geht nur darum, die Dinge nach Prio abzuarbeiten und dann das bereits geschaffene Ergebnis direkt nach Abschluss der Entwicklung abzunehmen – und über diese Fertigstellung Transparenz zu erzeugen. Sonst hat man “agilen Wasserfall” im Sprint – was auch nicht das Ziel ist (http://geek-and-poke.com/geekandpoke/2015/7/5/the-new-waterfall)
Hm. Das erscheint mir eine recht schwerwiegende Änderung zu sein: Entsteht da im Team nicht Frust, wenn der Fokus darauf liegt über fertige Arbeiten zu berichten statt auch (kleine) Fortschritte wahrzunehmen?
Den Hinweis kann ich nicht nachvollziehen. Die erste Frage ist doch statt „was habe ich gestern gemacht“ besser „Was habe ich seit dem letzten Daily Stand Up fertig gestellt?“ Zielt das nicht genau auf deinen Hinweis ab?
Ist kein Hinweis, sondern viel mehr eine Nachfrage.
Ich persönlich fände es auf jeden Fall frustrierend, wenn ich jeden darüber Tag berichten müsste, was ich nicht erreicht habe. Denn bei größeren Projekten liegt es ja irgendwie in der Natur der Sache, dass man nicht jeden Tag etwas fertigstellt – soll man ja auch nicht, das Ziel ist ja ein fertiges Inkrement am Ende einer Iteration.
Naja, vielleicht liegt es auch nur an mir. Aber siehst du noch weitere Möglichkeiten, wozu diese Formulierung führen kann?
Übrigens: Bei uns im Team hilft es, die Kollegen an den Zweck des Dailys zu erinnern, wenn sie ausschweifen. Mittlerweile machen das sogar die anderen Teammitglieder und die Detailfragen werden einfach im Anschluss geklärt.
Da bin ich anderer Meinung. Unabhängig vom persönlichen Frustfaktor ist es mehr als nur wichtig für das Team und das Sprintziel zu wissen, was geschafft wurde und was nicht.
Das Daily ist die Tagesplanung und die einzelnen Aufgaben jede Story sollten so weit runter gebrochen sein, dass sie innerhalb eines Tages angeschlossen werden können. Nur so lässt sich einfach Transparenz über den Fortschritt der Arbeit herstellen.
Dieser Beitrag von mir hier ist aber recht alt und zum erfolgreichen Daily gehört mehr als die drei Fragen.
Hier ein etwas jüngerer Artikel von mir, um aus einem Daily möglichst viel raus zu holen:
http://www.inspectandadapt.de/mehr-aus-dem-daily-rausholen/
Wir sind uns völlig einig darüber, dass es wichtig zu wissen ist, was geschafft wurde und was nicht. Worüber wir uns uneinig sind, ob da in Fließbandmanier jeden Tag fertige Arbeitspakete rausfallen müssen oder ob es erkennbare Fortschritte auch tun.
Ganz allgemein dient das Daily ja eigentlich dazu die Zusammenarbeit im Team zu optimieren, um wahrscheinlicher das Sprintziel zu erreichen.
Wie motiviert werden die Teamkollegen wohl sein, wenn sie sich von dem Daily unter Druck gesetzt fühlen? Wie förderlich wird das dann für das Sprintziel sein?
Aber dein neuerer Artikel klingt ja sehr stark danach, dass du wieder mehr zu einem Fortschritt-orientierten Daily übergegangen bist.
Wie erkennst du täglich einen Fortschritt, wenn Arbeitspakete nicht erkennbar abgeschlossen sind?
Und wie schließt du anhand des Beitrags darauf, dass ich nicht schon damals Fortschritt-orientiert im Daily vorgegangen bin? Für mich widersprichst du dir selbst damit.
Durch die Veränderung der Fragen ging und geht es mir doch gerade darum, den Fortschritt im Team transparent zu machen. Ich würde eher sagen, dass der zweite Beitrag die Erweiterung von ersten ist nach mehr Erfahrung.