Fragt man die meisten Manager nach der „psychologischen Sicherheit“ oder der „Vision“ (mehr dazu: Psychologische Sicherheit) ihrer agilen Softwareentwicklungs-Teams, stimmen sie zu, dass diese Dinge wichtig sind, aber… Wenn der Kunde Dringlichkeit signalisiert oder die Deadline näher rückt, werden all diese „weicheren“ Variablen typischerweise zurückgestellt. Den Managern geht es vor allem um einen vorhersehbar funktionierenden agilen Delivery Flow ihres agilen Teams.
Wenn Du mal in unserem Echometer-Blog (zu unserem Blog) gestöbert hast, weißt du, dass sich unsere Inhalte eher auf die Verbesserung der „Soft Skills“ von Teams und Organisationen konzentrieren. Diese werden von Entscheidungsträgern häufig unterschätzt. Aber nicht von Scrum Mastern und Agile Coaches.
Was Scrum Master und Agile Coaches meiner Meinung nach wiederum unterschätzen, ist Konzentration auf die Verbesserung des Delivery Flows – im Grunde das, was Manager wollen. Im heutigen Beitrag beschreibe ich eine einfache Technik, um die Wahrscheinlichkeit, wieder und wieder zeit- und budgetgerecht zu liefern, deutlich zu erhöhen.
1. Erster Schritt in Bezug auf euren Agile Delivery Flow
Ich spreche von der Überwachung des Agile Delivery Flows eurer Aufgaben bzw. Tasks. Wenn du nur ein paar Dinge richtig machst, wirst du in der Lage sein, wesentlich vorhersehbarere Ergebnisse zu liefern. Sogar deine Cycle Time Scatter Plots oder deine Monte-Carlo-Simulation zur Berechnung von Projektschätzungen könnten endlich valide Vorhersagen indizieren, anstatt völlig daneben zu liegen (mehr dazu: 9 Agile Metriken für Entscheidungsträger).
Erstes Symptom, das es zu bekämpfen gilt: Es gibt Tasks, die nur ein paar Tage von “Geplant” bis “Abgeschlossen” brauchen, und dann gibt es Tasks, die mehr als einen Monat in Anspruch nehmen. Um dem entgegenzuwirken, solltest du darauf achten, dass ein Task immer die kleinstmögliche lieferbare Version des gewünschten Features enthält. Ohne Schnick-Schnack, der für den Kern-Wunsch des Kunden nicht nötig ist. Im Grunde genommen ein MVT, Minimum Viable Task. Das bedeutet nicht, dass dadurch jeder Task klein ist. Aber es sollte euch helfen, ein Stadium zu erreichen, in dem Aufgaben eher höchstens ein paar Wochen und nicht Monate dauern.
2. Zweiter Schritt in Bezug auf deinen Agile Delivery Flow: WIP statt Velocity
Viele Scrum Master oder Kanban Coaches glauben, dass es für eine valide Messung von Velocity etc. auf das „right sizing“ von Tasks bzw. Workitems ankommt, bei dem alle Workitems ungefähr die gleiche Größe haben. Nur dann seien Story Points (die zur Messung der Velocity benötigt werden) für die Messung der Velocity brauchbar, weil sie eher wie eine vergleichbare Zeiteinheit erscheinen.
Aber das ist falsch: Tasks brauchen nicht einmal eine ähnliche Größe. Davon solltest du nicht ausgehen, denn es ist einfach zu schwierig, Story Point Schätzungen zu kontrollieren. Das Einzige, was du kontrollieren kannst, ist, wie viele neue Aufgaben du beginnst.
Tut also Folgendes, um vorhersehbar zu werden: Überwacht die Rate der „neu begonnenen Aufgaben“ im Vergleich zur Rate der „abgeschlossenen Aufgaben“. Diese beiden sollten im Gleichgewicht sein. Mit anderen Worten: Die “Eingangs-“ und die “Ausgangsrate” von Tasks sollten so nah wie möglich beieinander liegen, idealerweise sogar übereinstimmen.
Ein Beispiel: Typisches Verhalten in Software-Entwicklungsteams ist, dass man, sobald eine Aufgabe blockiert ist, ein neues Workitem beginnt. Das führt dazu, dass viele Aufgaben offen, aber unabgeschlossen sind, was es sehr viel komplizierter macht, sie alle wieder zu entblocken.
Wenn du stattdessen dafür sorgst, dass es für jeden begonnenen Task auch einen abgeschlossenen Task gibt, wird es im Daily besser gelingen, die wenigen fokussierten Aufgaben zu entblocken. Eure Leistung wird insgesamt berechenbarer – und das Team wird zufriedener sein, weil euer Vorgesetzter und eure Kunden zufriedener sind.
Einige „positive Symptome“ eines gesunden agilen Agile Delivery Flows
In der Praxis würde dies zu den folgenden Verhaltensweisen führen:
-
- Wir fangen keine neuen Aufgaben an, wenn noch viele Dinge in Arbeit sind.
-
- Wir konzentrieren uns darauf, das zu beenden, was wir angefangen haben, bevor wir neue Dinge beginnen.
-
- Das Alter der Aufgaben geht nie über ein paar Wochen hinaus.
-
- Wenn es keinen guten Grund dafür gibt, arbeiten wir immer am ältesten Task.
WIP-Limits (Work-in-Progress) helfen ebenfalls hierbei, auch wenn sie oft nicht ausreichen. Wenn das Team erst einmal gelernt hat, sich auf die Beendigung von Aufgaben zu konzentrieren, anstatt nur neue zu beginnen, werdet ihr besser sein als die meisten Teams.
Wenn man den Agile Delivery Flow richtig einsetzt
Um klare Erwartungen zu schaffen: Auf diese Weise kannst du immer noch nicht kontrollieren, ob eine Aufgabe zwei oder drei Tage dauert. Aber zumindest stellst du sicher, dass dein Team nicht an so vielen Aufgaben arbeitet, dass 2-3-Tages-Aufgaben am Ende einen Monat in Anspruch nehmen.
Wie viel besser würde es deinem Team schon gehen, wenn du wüsstest, dass grundsätzlich alle Lieferverpflichtungen innerhalb weniger Wochen erfüllt werden? Das setzt natürlich voraus, dass ihr alle oben genannten Dinge umsetzt: Die Festlegung von MVTs, ein striktes WIP-Limit und die Verpflichtung, Tasks erst dann neu zu beginnen, wenn ein anderer Task abgeschlossen wurde.
Schritt 3: Mit der Verbesserung des Agile Delivery Flows loslegen
In der Theorie weißt du, was zu tun ist. Wie kann man nun am besten praktisch loslegen? Indem du das Bewusstsein und die „Veränderungsbereitschaft“ im Team schaffst. Im besten Fall durch Selbstreflexion.
Du musst Transparenz über diese Zahlen schaffen und sie regelmäßig überprüfen, um zu sehen, ob das Verhältnis zwischen angefangenen und erledigten Tasks im Gleichgewicht ist. Es könnte Teil eurer Retrospektive sein, ein wenig tiefer zu gehen und zu reflektieren, warum die Zahlen im letzten Zyklus nicht im Gleichgewicht waren.
Ich kann empfehlen, die von mir erwähnten Verhaltensweisen mit unserem agilen Retrospektive Tool Echometer in eurer Retrospektive zu besprechen (mehr dazu: 7 Retrospektive Tools im Vergleich). Du könntest dies sogar zu einem Teil eurer Arbeitsvereinbarungen (bzw. Working Agreements) oder eures regelmäßigen Health Checks machen, um das Bewusstsein dafür zu schärfen, indem du die Fragen regelmäßig stellst.
Bei den folgenden Fragen handelt es sich um unser Retrospektive Template für die „agile Delivery“ (mehr dazu: 22 spaßige Templates für agile Retrospektiven). Wir beginnen mit ein paar Health Check Aussagen und fragen das Team, ob es eher zustimmt oder ablehnt. Danach gibt es ein paar offene Fragen:
Agile Delivery Retrospektive
Health Check Items
Wir erledigen die Dinge wirklich schnell. Kein Warten, keine Verzögerungen.
Wir können genau abschätzen, was wir in einem bestimmten Zyklus liefern können.
Unsere Sprint-Ergebnisse bedürfen keiner Nacharbeit nach dem Sprint, um ausgeliefert werden zu können.
Wir limitieren unseren 'Work in Progress', um jederzeit fokussiert zu sein.
Offene Fragen
Wann hat unsere Arbeitsweise wirklich gut funktioniert?
Welches sind die größten Verbesserungspotenziale, damit Arbeitspakete unsere Prozesse schneller durchlaufen (Wartezeiten beseitigen, Prozesse verbessern)?
Was waren kürzliche Beispiele für ein Inkrement, das am Ende des Sprints nicht funktionierte/auslieferbar war?
Wann hat unsere Arbeitsweise zu einem suboptimalen Arbeitsfluss geführt? (z. B. unklare, ungeeignete oder nicht befolgte Richtlinien)
Wie du dir denken kannst, impliziert der letzte Punkt des Health Checks (Prüfen der Ursache) bereits eine potenzielle Maßnahme, etwas, das du für ein bis zwei agile Sprints ausprobieren kannst, um zu sehen, ob es euch helfen könnte: Die Begrenzung der Anzahl von Tasks mit dem Status „Work in Progress“.
Das Fundament legen: Vereinbarungen für die Teamarbeit festlegen
Du hast das Gefühl, dass dein Team für diese Art der Reflexion noch nicht bereit ist? In diesem Fall solltest du zunächst über „gute Arbeit“ im Allgemeinen reflektieren und dann einige Grundregeln, so genannte Arbeitsvereinbarungen bzw. Working Agreements, festlegen. Die folgende Workshop-Vorlage kann euch dabei helfen. Du kannst sie als eine besondere Form der Retrospektive zu Beginn eines Projekts oder als zusätzlichen Workshop durchführen.
Zunächst solltest du ein Gefühl dafür bekommen, wie einig sich dein Team implizit fühlt – siehe dafür das Health Check Item. Dann solltest du dies mit ein paar offenen Fragen praktisch überprüfen. Jedes Teammitglied muss den Satz (siehe weitere Fragen) mit möglichst vielen Antworten beenden, die ihm/ihr in den Sinn kommen:
Team Commitments Retrospektive
Health Check Items
Wir haben in meinem Team ein gemeinsames Verständnis davon, was "gute Arbeit" ist.
Offene Fragen
Umgang mit widersprüchlichen Prioritäten: ‘Wenn ich widersprüchliche Prioritäten bemerke, dann ...’
Kommunikation von Blockern: ‘Wenn ich bei einer Aufgabe nicht weiterkomme, teile ich das, indem ich …’
Umgang mit Konflikten: ‘Wenn ich merke, dass ein Konflikt in unserem Team entsteht, dann ...’
Nachdem ihr die Antworten gesammelt habt, solltet ihr natürlich versuchen, Muster zu finden und euch auf konkrete Vereinbarungen darüber zu einigen, wie ihr in Zukunft zusammenarbeiten möchtet – zumindest vorübergehend als Experiment.
Eine interessante, kreative Alternative
Falls euch diese Retrospektive Methoden zu „trocken“ erscheinen, gibt es eine weitere Retrospektive Methode, die sich darauf konzentriert, die Qualität des Outputs deines Teams zu reflektieren (Spaßige 54 Retrospektive Methoden findest du hier): Die “Drei kleine Schweinchen) Retrospektive. Sie ist eine einfache Alternative, um mit der Reflexion und Verbesserung eurer Leistung zu beginnen, basierend auf dem Märchen von den drei kleinen Schweinen, die Häuser aus unterschiedlichen Materialien bauten.
Open Feedback Questions
Haus aus Stroh: Was haben wir gebaut, das gerade noch zusammenhält, aber jeden Moment umkippen könnte? 🌱
Haus aus Stöcken: Was haben wir gebaut, das relativ stabil ist, aber noch verbessert werden kann? 🪵
Haus aus Stein: Was haben wir gebaut, das grundsolide ist? 🪨
Fazit – Agile Delivery Flow
Egal, wie du anfängst: Das Wichtigste ist, überhaupt anzufangen. Die Teams, die ein aktives Auge auf ihren Agile Delivery Flow haben, sind die besseren Teams.
Übrigens sind viele der Ideen, die du hier findest, auch im Podcast „Agile Bites“ gut zusammengefasst, den ich sehr empfehlen kann (Zum Podcast: Agile Bites).
Viel Spaß beim Weiterentwickeln deines Teams!
