Mehr Value in 15 Minuten mit dem Value Driven Daily Scrum

In diesem Blog erfährst du, wie dein Team durch geringe Anpassungen im Daily Scrum Meeting sich deutlich stärker auf die wichtigen Dinge fokussieren kann und dadurch mehr Wert erzeugt.

Das Daily Scrum ist ein vergleichsweise einfaches Meeting - sollte man denken. Was soll man da noch groß verbessern können? In diesem Artikel soll der Ansatz des Value Driven Daily Scrum erläutert werden. Schauen wir zuerst, was der Scrum Guide zum bestehenden Scrum Daily dazu sagt.

Das Daily Scrum hat sich im Scrum Guide verändert - aus gutem Grund

Zunächst einmal zum eigentlichen Ziel des Daily Scrums:

“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work…

… The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Es fällt auf, dass

1. obwohl der Scrum Guide sonst an jedem Wort spart, taucht hier gleich zwei Mal das Wort “Fokus” auf, und zwar bezogen auf das Sprintziel, also den Wert.

2. Die berühmt gewordenen 3 Fragen tauchen nicht mehr auf (“What did you do yesterday? What will you do today? Are there any blockers or impediments preventing you from doing your work?)

In der Praxis spricht oft jedes Team Member nacheinander über alle „ihn direkt betreffenden“ Stories.

Die im alten Scrum Guide noch enthaltenen drei Fragen haben sich häufig etabliert. Jeder Entwickler trägt seinen Teil einzeln vor und nacheinander. Dieser Aspekt ist wichtig, denn er führt dazu, dass man thematisch permanent zwischen den angesprochenen PBIs wechselt. Dadurch verliert sich der Fokus auf das aktuell wichtigste in Bearbeitung befindliche Backlog Item.

Das Value Driven Daily Scrum stellt die Prioritäten in den Vordergrund, nicht wer daran arbeitet.

Der Ansatz des Value Driven Daily Scrums ist extrem einfach:

Falls nicht ohnehin schon gesehen, sollten wir im Scrum Guide empfohlen die Sprint Backlog Items bzw. die Items auf dem Scrum Board im Planning dort nach Priorisierung aufgehängt sein. Auch das Sprint Ziel sollte gut sichtbar für alle sein.

Jetzt kommt die eine, kleine Veränderung mit großer Wirkung: Jede Story soll nacheinander durchgegangen werden. Beginnend mit dem wichtigsten PBI soll sich jeder äußern der eine Aktivität übernehmen möchte, solange bis es nicht mehr sinnvoll möglich ist mit weiteren Teammitgliedern an dem Thema zu arbeiten bzw. bis alle Teammitglieder für den Tag ausgelastet sind. Das ist alles. Was Impediments angeht verhält es sich analog: Ist ein Impediment zum aktuell besprochenen PBI bekannt, wird erst prioritär gelöst. Bekannte Impediments zu deprioren PBIs werden erst dann bearbeitet, wenn das entsprechende PBI drankommt. Erst wenn es zu einer Story nichts zu sagen gibt, macht man weiter. Das ist alles. Es soll eben nicht mehr so sein, dass jeder zu allen “ihn betreffenden” Items nacheinander spricht.

Implizit bedeutet dieses Vorgehen auch, dass die drei Fragen weggelassen werden. Wie wichtig ist es, über die Arbeit von gestern zu sprechen? Auch wenn es im Einzelfall Gründe geben kann, ist meistens ist nur das, was noch zu tun ist, wirklich interessant. Beim Value Driven Ansatz ist durch den geringeren WIP ohnehin deutlich mehr bekannt, woran gerade gearbeitet wird, da kann man über das, was gestern getan wurde, auch schweigen. Auch die Frage “Was tue ich heute” erübrigt sich, da jeder sich ohnehin zu den PBIs äußert, wenn sie dran sind.

Das Daily Scrum ist beendet, wenn aus Kapazitätsgründen kein Team Member sich weitere Tasks für den Tag vornehmen kann.

Vorteile des Value Driven Daily Scrum

Im Prinzip drehen sich durch dieses Vorgehen alle oben genannten Nachteile des bisherigen, klassischen Vorgehens im Daily in Vorteile um, und es kommen noch weitere Vorteile dazu:

1. Hilfestellung zur Einhaltung der Prioritäten Zunächst einmal bietet das Vorgehen Orientierung, welches PBI jeweils das nächste sein sollte. Theoretisch ist das klar, in der Praxis erlebe ich jedoch immer wieder, dass aus verschiedenen Gründen nicht das wichtigste Thema als nächstes angefangen wird. Dafür kann es gute Gründe geben, und auch persönliche Vorlieben können ein guter Grund sein. Die Entscheidung sollte aber transparent und gemeinsam im Team getroffen werden.

2. Reduzierung des WIP Dadurch wird an weniger PBIs gleichzeitig gearbeitet. Parallelisierung wird befördert. Es wird normal, sich zu überlegen, wie man gemeinsam an einem Thema arbeiten kann.

3. Erhöhter Austausch und erhöhtes Lernen Durch die WIP-Reduzierung erhöht sich die Zusammenarbeit im Team, die Rate von Pair Programming, das gegenseitige Lernen.

4. Erhöhte Transparenz über den Fortschritt Dadurch, dass man immer an den wichtigsten Themen arbeitet, sind auf priorisierten Scrum Board die “Done”-Items immer oben. Darunter kommen die Items “In Work” und darunter die Items die noch in “To Do” sind. Extrem übersichtlich. Es wird leichter zu erkennen, ob das Sprintziel ggf. gefährdet ist.

5. Erhöhte Reaktionsfähigkeit bei gefährdetem Sprintziel Das wiederum erlaubt es, rechtzeitig Maßnahmen einzuleiten, z.B. mit dem Product Owner zu verhandeln, wie das Sprintziel ggf. mit Abstrichen erreicht werden kann. Ggf. kann man eine User Story nachträglich schneiden und weniger wichtige Aspekte in den nächsten Sprint verlagern. Oder externe Teams früher um Hilfe bitten bei wichtigen Impediments, insbesondere bei solchen die nur außerhalb des Teams gelöst werden können.

6. Geringere Schwankung der Velocity Wenn weniger gleichzeitig in Bearbeitung ist, erhöht das die Wahrscheinlichkeit, dass mehrere PBIs gleichzeitig am Sprintende nicht fertig sind und dann in den nächsten Sprint wandern. Dadurch schwankt die Velocity weniger stark. Dadurch hat das Team eine erhöhte Fähigkeit, bei vorliegenden Schätzungen enge Zeitkorridore zu wahrscheinlichen Fertigstellungsterminen abzugeben.

7. Erhöhte Fähigkeit, Impediments wegzuräumen und erhöhte Velocity Da nun mehr Team Member an den gleichen Themen arbeiten, betreffen aufkommende Impediments, die nur ein PBI betreffen, auch mehr Personen als vorher. Das Impediment wird stärker als Team-Impediment betrachtet. Dadurch erhöht sich die Wahrscheinlichkeit deutlich, dass das Impediment schnell gelöst wird, wodurch wiederum die Velocity steigt.

8. Erhöhter Teamzusammenhalt Das verstärkt gemeinsame Wegräumen der Impediments erhöht den Austausch im Team und führt zu häufigeren gemeinsamen Erfolgserlebnissen.

9. Erhöhte Wahrscheinlichkeit das Sprint-Ziel zu erreichen Fast alle oben genannten Punkte zahlen positiv auf die Wahrscheinlichkeit ein, dass die wichtigsten PBIs und damit das Sprint-Ziel erreicht wird.

Es gibt auch Nachteile

Wo so viele Vorteile sind, muss es auch Nachteile geben.

1. Ungleiche Redeanteile Man muss zugeben: extrovertierte Team Member werden in diesem Vorgehen einen höheren Redeanteil bekommen, introvertierte eher anderen den Vortritt lassen. Das kann im schlimmsten Falle Konflikte verursachen oder andere negative Folgen haben. Der Scrum Master sollte darauf achten und ggf. dies in Retrospektiven thematisieren.

2. Man kann sich verstecken Dies ist eigentlich eine Sonderform des obigen Aspekts. In jedem Team, auch in agilen Teams, kann es einzelne Personen geben, die die Arbeit nicht als den Kern ihres Lebens ansehen. Motivation kann stark steigen, nicht nur zwischen einzelnen Personen, sondern auch abhängig von der Tagesform einzelner oder den aktuellen Themen im Sprint, die vielleicht nicht jeden gleichermaßen begeistern. Kurz: Falls es jemand im Team gibt, der wenig motiviert ist, und sich am liebsten der Arbeit enthalten möchte, wird dies in diesem Ansatz deutlich weniger transparent als bisher.

Fazit

Mein persönliches Fazit: Wenn die Velocity steigt und die Wahrscheinlichkeit, das Sprint-Ziel zu erreichen, steigt, so wird insgesamt eine Menge Wert, eine Menge “Business Value” mehr erreicht als im üblichen Ansatz. Die Vorteile überwiegen meines Erachtens deutlich. Man bedenke, wie wenig man dafür ändern muss.

Es würde mich sehr freuen, wenn dieser Blog das ein oder andere Team zum Experimentieren anregt.

Feedback bitte an: christain.humphreys@senta-agile-consulting.de