Wie sich das Statusmeeting in die agile Welt gerettet hat

Von |2018-01-19T07:58:58+00:0028. Oktober 2017|Agile Methoden|0 Kommentare
5 Minuten Lesedauer

TL;DR

Konzentriere dich in Standups nicht auf den Status der einzelnen Mitglieder. Fokussiere den Status der gesamten Arbeit des Team zum erreichen des gesetzten Ziels. Fast so, wie es der „Scrum Guide“ vorschlägt, aber nur fast …

Gehe weg von:

  1. Was habe ich gestern getan?
  2. Was werde ich heute tun?
  3. Bin ich durch etwas blockiert?

Hin zu:

  1. Welche Aufgaben müssen wir sinnvollerweise als nächstes abschließen?
  2. Haben wir Aufgaben, die wir nicht oder nur unter Schwierigkeiten fertig bekommen?
  3. Was können wir tun, das Risiko aus diesen Aufgaben rauszunehmen?

Die etwas längere Fassung

Hände hoch – oder der Nachvollziehbarkeit halber doch einfach nur einen Kommentar – wer sie nicht kennt: Die scheinbar endlosen Treffen am Aufgaben-Board, welche einem die Füße selbst im Stehen einschlafen lassen:

Jan: Gestern habe ich mich an die Aufgaben für die Implementierung der Word-Ausgabe des CVs gesetzt und die ersten APIs evaluiert. Ergebnis war, dass ich eine prioirisierte Auswahl getroffen habe, die euch heute im Anschluss wie angekündigt gerne vorstellen würde. An der Auswahl von uns würde ich heute weiterarbeiten und das erste Word-Dokument angehen.

Ich war kurzfristig blockiert, da das Internet mal wieder nicht vernünftig funktioniert hat. Vielleicht sollten wir hier eine Aufgabe erstellen…?!?

Sascha: Ich habe gestern vor allem an der GUI gearbeitet und konnte endlich das Hauptmenü fertigstellen. Ich werde das heute im Anschluss mit unserem PO durchsprechen und schauen, ob hier noch etwas abgerundet werden muss. Zusätzlich bin ich noch in diversen Architektur-Meetings unterwegs … Blockiert bin ich derzeit durch nichts.

Und, wiedererkannt? Jetzt stellt sich natürlich die Frage, was ich an dem Vorgehen auszusetzen habe. Grundsätzlich läuft es ja fast nach der von vielen gepredigten und falsch gelebten „Dreifaltigkeit“ des Scrum-Daily…

Ich als Teammitglied kann in so einer Situation nicht erkennen, wie der Status des Teams ist und ob wir das versprochene Ziel erreichen. Schlimmer noch, wenn ich das erkennen will, muss ich aktiv zuhören und gleichzeitig die Situation des einzelnen auf den Teamstatus übertragen. Mal ganz davon abgesehen, dass ich vor allem in kritischen Situationen gegen Multitasking bin, sehe ich hier eine fehleranfälligen und für den einzelnen unnötige Aktion. Warum kümmern wir uns nichts als Team um den Fortschritt unserer Arbeit in Richtung unseres gemeinsamen Ziels?

Das Vorgehen erfordert eine kleine Anpassung im Meeting. Nicht die Personen, sondern die Aufgaben stehen im Vordergrund. Für den Ablauf, kann natürlich alles gewählt werden. Gute Erfahrungen habe ich allerdings damit gemacht, mit den Aufgaben zu starten, die kurz vor der Fertigstellung sind und danach auf die kritischen Themen zu beachten und zu bearbeiten:

Sascha: Ich bin mit der „Aufgabe #46 – Umsetzung GUI für das Hauptmenü“ fast fertig und muss nur noch ein Feedback vom PO einholen. Die Vorabnahme sollte nur kleinere Punkte zur Anpassung ergeben. Ich hätte also Zeit für etwas Neues…

Jan: Das trifft sich ganz gut, was hältst du denn davon schon direkt mit der „Aufgabe #29 – Maske für die Erstellung der Rechnung als Word-Dokument“ zu starten? In dem Anschlusstreffen mit euch, will ich die „Aufgabe #27 – Evaluierung und Festlegung der zu nutzenden Word-API“ mit euch abstimmen. Mit allen APIs bin ich so vertraut, dass ich recht schnell in die „Aufgabe #28 – Prototypische Umsetzung ohne Layout der Rechnung als Word-Dokument“. Dann könnten wir das im Pair-Programming erledigen… Ich glaube, dass wir damit bis Morgen die zwei für diesen Sprint wichtigsten Themen abschließen können und dem PO eine Woche vor Sprint-Abschluss eine Chance auf Feedback geben.

Sascha: Cool, selbst wenn wir da eher schlechtes Feedback bekommen, haben wir noch genug Zeit das ganze noch einmal ohne Risiko für das Sprint-Ziel auf Links zu drehen.
Haben wir noch Themen, die wichtiger sind und die wir vorher angehen müssten? Irgendwelche Abhängigkeiten, oder Themen die einen gewissen Vorlauf haben wie die „Aufgabe #19 – Bestellung Hardware für die neue Kollegin Schiller“? Das letzte mal hat der ganze Bestellprozess ja locker vier Werktage gebraucht.

Jan: Ah, stimmt. Gute Idee! Lass mich das einfach dann machen, während du in der Abnahme durch den PO bist.

Damit ergibt sich fast natürlich die Konzentration auf die Arbeit. Ergänzt man jetzt noch, dass erst die wichtigste – meistens ganz oben hängende – User Story (oder Anforderung) und deren Arbeitsstand besprochen wird, arbeiten wir als Team sogar immer ganz im Sinne des Product Owners fokussiert an den wichtigsten Themen zuerst. Wenn das mal kein Lächeln erzeugt!

Pragtics - Daily am Board

Natürlich wird es mit dem Vorgehen Teammitglieder geben, die nicht zu allen Themen etwas sagen werden. Aber auch für diese werden die jeweils zugeordneten Aufgaben irgendwann kurz vor ihrem Abschluss stehen, oder in der Diskussion über Aufgaben die Schwierigkeiten bei ihrem Abschluss haben in den Fokus geraten.

Mit dem gezeigtem Vorgehen habe ich persönlich viel bessere Erfahrungen gemacht als mit der leicht falsch zu verstehenden „Dreifaltigkeit“. Erstens steht ganz natürlich der Abschluss von Arbeit im Fokus – und wie jeder weiß ist nur fertige Arbeit wirklich fertig. Zweitens schlafen nicht allen die Füße ein, weil jeder die gleiche Leier runterspült, sondern es wirklich darum geht, dass was geschafft wird.