Eine Veränderung nach der anderen

In einem der zwölf Prinzipien des Agilen Manifests heißt es: "In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und stimmt sein Verhalten entsprechend ab und passt es an. Viele agile Teams halten zweiwöchentliche Retrospektiven ab, die zu konkreten Aktionen führen, die im nächsten Zeitabschnitt (Sprint) ausgeführt werden. Es gibt viele Arten von Abstimmungen und Anpassungen, die ein Team vornehmen kann, z. B. die Verbesserung des Arbeitsablaufs, die Automatisierung von Aufgaben und die Verbesserung der Zusammenarbeit im Team. Ist es eine gute Angewohnheit, sich bei Retrospektiven auf dieselbe Art von Verbesserungen zu konzentrieren, oder sollte das Team die Art der Verbesserungen ändern? In diesem Blog befasse ich mich mit den Auswirkungen mehrerer aufeinanderfolgender Aktionen, die den Arbeitsfluss beeinflussen. Die Simulation ist inspiriert vom getKanban Board Game, einem physischen Spiel, das entwickelt wurde, um die Konzepte und Mechanismen von Kanban für die Softwareentwicklung in einer Klasse oder einem Workshop zu vermitteln.

Ein Experiment

Im Idealfall würde ein Experiment zwei gleichwertige Teams miteinander vergleichen. Das erste Team würde nacheinander Aktionen zur Verbesserung des Arbeitsablaufs durchführen, während das andere Team nur eine Anpassung zur Verbesserung des Arbeitsablaufs vornehmen und sich dann auf nachfolgende Verbesserungen in anderen Bereichen konzentrieren würde. Nach einer bestimmten Zeit würde der Arbeitsablauf bei beiden Teams gleichzeitig gemessen und überprüft werden, um festzustellen, welches Team bessere Ergebnisse erzielt hat. Aber ein solches Experiment ist schwierig durchzuführen, daher werde ich in diesem Blog eine Simulation verwenden.

Simulation

Bei dieser Simulation besteht ein Team aus drei Spezialisten: einem Designer, einem Entwickler und einem Tester. Das Team verwendet einen Kanban-Prozess, um den Arbeitsfluss zu gewährleisten. In der Abbildung unten sehen Sie die Ausgangssituation. Das Team legt zu Beginn eines jeden Arbeitstages fest, wie viel Arbeit es erledigen wird, und die durchschnittliche Durchlaufzeit wird während der Simulation gemessen. Die anfänglichen WIP-Grenzen (Work in Progress) werden für jede Spalte auf 3 gesetzt, was durch die roten 3en angezeigt wird. Der durchschnittliche Arbeitsaufwand des Teams und der durchschnittliche Aufwand für ein Arbeitspaket sind so bemessen, dass eine Karte im Durchschnitt etwa 5,5 Tage zur Fertigstellung benötigt. Am Ende eines jeden Arbeitstages werden die Karten in die nächsten Spalten gezogen (sofern die WIP-Limits dies zulassen). Es gilt die Regel, immer so viel Arbeit wie möglich hineinzuziehen, damit die Spalten maximal gefüllt sind. Außerdem wird davon ausgegangen, dass das Backlog immer genügend User Stories enthält, die in die Spalte "Design" gezogen werden können. Dies ist vergleichbar mit der Entwicklung eines neuen Produkts, bei der das Backlog mit mehr als genug Stories gefüllt ist. Das System startet mit einem sauberen Brett und allen leeren Spalten. Nachdem wir das System fünfundsiebzig simulierte Arbeitstage lang laufen lassen haben, lösen wir eine Richtlinienänderung aus und erhöhen das WIP-Limit für den Entwurf von drei auf fünf. Nach dieser Richtlinienänderung läuft das System für weitere 100 Arbeitstage. Anhand des Diagramms, das die durchschnittliche Zykluszeit anzeigt, können wir die Auswirkungen von Anpassungen des WIP-Limits untersuchen.

Anmerkung:

Die Simulation geht von einer einfachen Gleichverteilung für die vom Team geleistete Arbeit und den einem Arbeitsgegenstand zugewiesenen Aufwand aus. Ich nehme an, dass dies für den Zweck dieses Blogs in Ordnung ist. Eine Folge davon ist, dass das Ergebnis wahrscheinlich nicht skaliert werden kann. So ist beispielsweise die Situation, in der eine Spalte in der obigen Abbildung ein einzelnes Scrum-Team darstellt, nicht anwendbar, da anstelle der Gleichverteilung eine komplexere Wahrscheinlichkeitsverteilung verwendet werden sollte.

Ergebnisse

Das Bild unten zeigt das Ergebnis des Experiments.  

Nach dem Start braucht das System etwas mehr als 40 Arbeitstage, um den stabilen Zustand einer durchschnittlichen Zykluszeit von etwa 24* Tagen zu erreichen. Dies ist die Zykluszeit, die man erwarten würde. Denken Sie daran, dass die Spalte "Bereit" ein Limit von 3 hat und die anderen Spalten bearbeitet werden. Man würde also eine Zykluszeit von etwa 4 mal 5,5 erwarten, was 22 Tagen entspricht - fast 24. Am Tag 75 wird das WIP-Limit geändert. Wie Sie der Abbildung entnehmen können, beginnt die Zykluszeit erst an Tag 100 zu steigen (es dauert etwa eine Zykluszeit (24 Tage), um zu reagieren). Der neue stabile Zustand wird an Tag 145 erreicht, mit einer durchschnittlichen Zykluszeit von etwa 30** Tagen. Es dauert 70 Tage (!), bis das neue Gleichgewicht erreicht ist. Die Grafik zeigt die folgenden interessanten Merkmale:

• Es dauert etwa doppelt so lange wie die (neue) durchschnittliche Zykluszeit, um den Gleichgewichtszustand zu erreichen.
• Die Reaktionszeit (d.h. der Zeitpunkt, an dem Sie eine Auswirkung der Richtlinienänderung bemerken) entspricht in etwa der Länge der durchschnittlichen Zykluszeit.

*Man kann (mit Hilfe von Übergangsmatrizen) die theoretische durchschnittliche Zykluszeit für dieses System auf 24 Tage berechnen. **Die theoretische durchschnittliche Zykluszeit des Systems nach einer Richtlinienänderung beträgt 31 Tage.

Fazit

In diesem Blog haben wir gesehen, dass, wenn ein Team Anpassungen vornimmt, die sich auf den Ablauf auswirken, das System Zeit braucht, um seinen neuen stabilen Zustand zu erreichen. Bis dieser Zustand erreicht ist, ist jede neue Abstimmung des Ablaufs fragwürdig. Simulationen zeigen, dass die Zeit, die benötigt wird, um den neuen stabilen Zustand zu erreichen, etwa das Zweifache der durchschnittlichen Zykluszeit beträgt. Bei Scrum-Teams, die zweiwöchige Sprints haben, braucht das System möglicherweise etwa zwei Monate, bis eine neue Abstimmung des Ablaufs wirksam ist. In der Zwischenzeit kann sich das Team sehr gut auf andere Verbesserungen konzentrieren, z.B. Retrospektiven, die sich auf den Teamaspekt oder die Zusammenarbeit mit dem Umfeld des Teams konzentrieren. Erwarten Sie außerdem nicht, dass sich die Messungen z.B. der Zykluszeit innerhalb des Zeitraums der durchschnittlichen Zykluszeit ändern, nachdem Sie eine den Fluss beeinflussende Änderung vorgenommen haben. Zusammenfassend lässt sich sagen, dass Sie nach Änderungen, die sich auf den Ablauf auswirken (z.B. Erhöhung oder Senkung der WIP-Limits), die

• Lassen Sie das System mindestens für die Dauer der durchschnittlichen Zykluszeit laufen, damit es Zeit hat, auf die Änderung zu reagieren.
• Achten Sie auf die Auswirkung der Änderung, nachdem er geantwortet hat.
• Wenn der Effekt positiv ist, lassen Sie das System für eine weitere Dauer der durchschnittlichen Zykluszeit laufen, um den neuen stabilen Zustand zu erreichen.
• Wenn der Effekt negativ ist, tun Sie etwas anderes, z.B. kehren Sie zum alten Zustand zurück, und denken Sie daran, dass das System auch darauf reagieren muss!