Verbessert die Einführung von Agile-Ansätzen wirklich die Software Delivery Performance von dir und deinem Team? Und wenn ja, welche Methodik ist besser? Scrum, Kanban oder eXtreme Programming?
Es ist nicht einfach, die positiven Auswirkungen der Einführung von Agile-Praktiken zu messen. Kein Softwareprojekt ist gleich. Und es ist leider unmöglich, in der Zeit zurückzugehen und es anders zu machen.
Aber es gibt eine großartige Möglichkeit, die Auswirkungen verschiedener Agile-Methoden zu visualisieren:
Das Penny-Spiel
Das Penny-Spiel ist eine unterhaltsame Aktivität für Ihr Team und hilft dabei zu verstehen, wie sich das Reduzieren von Arbeitspaketen, entgegen der Intuition, positiv auf die Produktionssysteme auswirkt.
Das Ziel des Penny-Spiels ist es, 20 Produkte herzustellen und zu versenden, die durch 20 Münzen dargestellt werden, die entweder Kopf oder Zahl zeigen.
Jede Münze (Produkt) muss 4 Arbeitsstationen durchlaufen, bevor sie dem Kunden zur Inspektion übergeben werden kann. Jede Arbeitsstation wird von einem Teammitglied (Arbeiter) repräsentiert, und jedes Teammitglied muss jede Münze zweimal umdrehen – nacheinander, wobei nur die linke Hand verwendet wird.
Runde 1 von 4
In der ersten Runde beträgt die Paketgröße 20 (entspricht der Anzahl aller Münzen). Das bedeutet, dass Arbeiter 1 alle 20 Münzen der Charge umdrehen muss, bevor er das Paket an die nächste Arbeitsstation von Arbeiter 2 weitergeben darf. Dann muss Arbeiter 2 alle Münzen umdrehen, bevor er die Charge an Arbeiter 3 weitergeben darf. Und so weiter, und so fort.
Der Rest des Teams beobachtet die Arbeiter und misst die Zeit, die vergeht, bis der Kunde die erste Münze und die letzte Münze (alle Münzen) erhält.
| Runde 1 | Runde 1 | Runde 2 | Runde 3 | Runde 4 |
|---|---|---|---|---|
| Paketgröße | 20 | |||
| Erste Lieferung | 5:17 | |||
| Letzte Lieferung | 5:17 |
In dem oben genannten Fall benötigt das Team 5 Minuten und 17 Sekunden, um die 20 Münzen (Produkte) abzuliefern.
Wir haben nur einen Paket mit 20 Münzen, daher kommt die erste Münze gleichzeitig mit der letzten an.
Fehlerquote
Ich spiele normalerweise den Kunden und an dieser Stelle bringe ich normalerweise ein wenig Schwung hinein:
Sobald ich die Charge Münzen erhalte, werfe ich eine Münze und kündige an, dass ich lieber Kopf statt Zahl möchte. Ich mache dies, um die sich ständig ändernden Anforderungen in Softwareprojekten zu simulieren.
Wenn zu Beginn alle Münzen zufällig Kopf und Zahl zeigen und wenn alle Arbeiter die Münze genau zweimal drehen, werde ich im Durchschnitt 10 Köpfe und 10 Zahlen erhalten.
Tatsächlich erhalte ich jedoch 11 Münzen, die Zahl zeigen, anstatt 20 Köpfe. Das entspricht einer Fehlerquote von 55%!
| Metriken | Runde 1 | Runde 2 | Runde 3 | Runde 4 |
|---|---|---|---|---|
| Paketgröße | 20 | |||
| Erste Lieferung | 5:17 | |||
| Letzte Lieferung | 5:17 | |||
| Fehlerquote | 55% |
Es sieht so aus, als müsste das Team etwas Zeit mit ungeplanten Nacharbeiten verbringen.
Wasserfall
Ich vergleiche diese erste Runde mit nur einer Charge gerne mit einem Softwareprojekt, das einen traditionellen Wasserfallansatz verwendet.
In einem Wasserfallprojekt wird die Projektzeit in verschiedene Phasen unterteilt:
Die Charge Münzen repräsentiert eine Sammlung aller Features. Alle Features werden gemeinsam geplant, eingebaut, getestet und am Ende des Projekts dem Kunden als ein finales Produkt (eine Charge) übergeben.
Oft sind Personen aus verschiedenen Abteilungen für die unterschiedlichen Projektphasen verantwortlich. Zwischen den Abteilungen verwenden sie formelle und zeitaufwändige Übergaben, um sicherzustellen, dass nicht sie es sind, die das Projekt gefährden.
Ob die Features von guter Qualität sind, wird erst am Ende des Projekts festgestellt. Es gibt eine manuelle Testphase, und die Endnutzer können erst nach Erhalt des Produkts Feedback dazu abgeben.
In einem Wasserfallprojekt gibt es im Wesentlichen einen großen Feedbackzyklus:
Aber das Feedback kommt zu spät. Viele Funktionen des gelieferten Produkts sind fehlerhaft oder in ihrem aktuellen Zustand unbrauchbar.
Wasserfallprojekte überschreiten oft die Fristen und das Budget aufgrund von unvorhergesehenen zusätzlichen Arbeiten, die erst am Ende des Projekts oder nach der Lieferung des Produkts entdeckt werden.
Runde 2 von 4
Zurück zum Penny-Spiel.
In Runde 2 wird die Paketgröße halbiert. Das bedeutet, dass jeder Arbeiter die ersten 10 Münzen umdrehen muss und dann die Charge an die nächste Arbeitsstation weitergeben darf, bevor er mit dem Umdrehen der verbleibenden 10 Münzen fortfährt.
Der Rest des Teams beobachtet erneut die Arbeiter und misst den Prozess.
Sobald der Kunde die erste Münze (als Teil der ersten Charge mit 10 Münzen) erhält, werfe ich eine Münze und kündige an:
„Der Kunde möchte Zahl; bitte stellt sicher, dass alle nicht gelieferten Münzen Zahl zeigen!“
Die Arbeiter dürfen nun ein drittes Mal eine Münze werfen, um dies zu erreichen.
Die erste Charge enthielt 5 unerwünschte Münzen mit Zahl, und das Team schaffte es, mit der zweiten Charge nur Münzen mit Kopf zu liefern.
Hier sind die Resultate von Runde 2:
| Metriken | Runde 1 | Runde 2 | Runde 3 | Runde 4 |
|---|---|---|---|---|
| Arbeitspaketgröße | 20 | 10 | ||
| Erste Lieferung | 5:17 | 2:39 | ||
| Letzte Lieferung | 5:17 | 3:12 | ||
| Fehlerquote | 55% | 25% |
Zunächst stellen wir fest, dass der Kunde das erste Produkt (die Münze) nach 2 Minuten und 39 Sekunden erhält. Das ist etwa doppelt so schnell im Vergleich zu Runde 1.
Und mit insgesamt 3 Minuten und 12 Sekunden dauerte es 2 Minuten weniger, um alle Produkte zu liefern.
Die Fehlerquote sank von 55 % auf 25 %.
Scrum
Die zweite Runde kann mit einem Projekt verglichen werden, das Scrum als Entwicklungsansatz verwendet.
In Scrum arbeitet ein funktionsübergreifendes Entwicklerteam in 4-wöchigen Iterationen, die Sprints genannt werden, an dem Produkt.
Pro Sprint konzentriert sich das Team nur auf einige wenige Funktionen. Das Team plant, baut ein und testet die Funktionen. Am Ende jedes Sprints liefern sie das Set an Funktionen und erhalten Feedback.
Frühes Feedback und enge Zusammenarbeit (funktionsübergreifende Teams vs. Abteilungen) tragen dazu bei, die Projektzeit zu verkürzen und die Qualität erheblich zu steigern.
Runde 3 von 4
Die Paketgröße wird in der dritten Runde des Penny-Spiels erneut halbiert. Jetzt muss jeder Arbeiter 5 Münzen drehen, bevor er 5 Münzen an die nächsten Arbeitsstationen weitergibt und mit dem Drehen des nächsten Sets von 5 Münzen fortfährt.
Während der Rest des Teams den Prozess mit ihren Stoppuhren verfolgt, entscheidet der Kunde, ob er Kopf oder Zahl möchte. Sobald ich die erste Charge von 5 Münzen erhalte, werfe ich eine Münze und kündige an: „Zahl!“.
Die erste Charge enthält 2 Münzen, die Kopf zeigen.
Für die verbleibenden 3 Chargen darf das Team eine Münze dreimal werfen, um sicherzustellen, dass der Kunde nur Münzen mit Zahl erhält.
Hier sind die Ergebnisse von Runde 3:
| Metriken | Runde 1 | Runde 2 | Runde 3 | Runde 4 |
|---|---|---|---|---|
| Arbeitspaketgröße | 20 | 10 | 5 | |
| Erste Lieferung | 5:17 | 2:39 | 1:15 | |
| Letzte Lieferung | 5:17 | 3:12 | 2:56 | |
| Fehlerquote | 55% | 25% | 10% |
Wir stellen fest, dass die Dauer bis zur Lieferung der ersten Münze mit 1 Minute und 15 Sekunden erneut halbiert wird (ein Viertel im Vergleich zu Runde 1).
Die gesamte Lieferzeit beträgt jetzt weniger als 3 Minuten, und die Fehlerquote liegt nur bei 10 %.
Kanban
Wir können die dritte Runde mit einem Projekt vergleichen, das Kanban als Entwicklungsansatz verwendet.
Ein Kanban-Team arbeitet in wöchentlichen Iterationen und begrenzt die laufenden Arbeiten, um Kontextwechsel zu vermeiden.
Jede Woche reflektieren sie darüber, wie sie den Entwicklungsprozess verbessern können und holen Feedback von ihrem Kunden oder den Endnutzern ein.
Ein Kanban-Board hilft dem Team, die laufenden Arbeiten zu visualisieren und zu optimieren.
Kein Entwickler darf gleichzeitig an mehr als einem Feature arbeiten (One-Piece-Flow). Bevor ein Entwickler mit einem neuen Feature beginnen kann, muss er sicherstellen, dass kein anderes unfertiges Feature noch in Arbeit ist und Unterstützung benötigt (z. B. eine ausstehende Code-Überprüfung).
Ein wichtiges Kanban-Prinzip ist:
Hör auf zu starten; fang an zu beenden!
Das Ergebnis noch kürzerer Feedbackschleifen und noch engerer Zusammenarbeit unter den Teammitgliedern ist ein ständiger Fluss von vollständig getesteten und integrierten Features während der Arbeitswoche.
Mit Kanban werden die gesamte Lieferzeit und die Fehlerquote weiter reduziert.
Können wir das noch übertreffen?
Bisher haben wir gesehen, dass die Reduzierung der Arbeitspaketgröße zu kürzeren Feedbackschleifen führt. Und kürzere Feedbackschleifen führen zu einer Verkürzung der Lieferzeit und einer erhöhten Qualität.
Es scheint vernünftig anzunehmen, dass, wenn es uns gelingt, die Arbeitspaketgröße weiter zu reduzieren, die Lieferzeit sinken und die Qualität noch weiter steigen wird.
Aber nehmen wir an, die Paketgröße in der Softwareentwicklung ist bereits auf je ein Feature zeitgleich (Kanban) reduziert.
Welche Praktiken könnten möglicherweise zu noch kürzeren Feedbackschleifen und engerer Zusammenarbeit führen?
Runde 4 von 4
Es ist Zeit für die letzte Runde des Penny-Spiels.
Diesmal beträgt die Paketgröße 1 Münze. Das bedeutet, dass jeder Arbeiter eine Münze zweimal dreht und sie dann sofort an die nächste Arbeitsstation weitergibt.
Sobald der Kunde die erste Münze erhält (sie zeigt Zahl), kündige ich an, dass der Kunde nur „Kopf!“ möchte.
Hier sind die Ergebnisse von Runde 4:
| Metriken | Runde 1 | Runde 2 | Runde 3 | Runde 4 |
|---|---|---|---|---|
| Arbeitspaketgröße | 20 | 10 | 5 | 1 |
| Erste Lieferung | 5:17 | 2:39 | 1:15 | 0:36 |
| Letzte Lieferung | 5:17 | 3:12 | 2:56 | 2:42 |
| Fehlerquote | 55% | 25% | 10% | 5% |
Nach nur 36 Sekunden erhält der Kunde seine erste Münze (Produkt). Sie ist fehlerhaft, aber das frühe Feedback ermöglicht es dem Team, 19 Münzen von guter Qualität zu liefern. Die Fehlerquote sinkt auf 5 Prozent.
Die gesamte Lieferzeit beträgt 2 Minuten und 42 Sekunden, was erneut etwas niedriger ist im Vergleich zu Runde 3 und etwa der Hälfte von Runde 1.
eXtreme Programming (XP)
Ich vergleiche Runde 4 gerne mit einem Projekt, das eXtreme Programming als Entwicklungsansatz verwendet.
eXtreme Programming (XP) bringt alles, was in der Softwareentwicklung funktioniert, auf die „extreme“ Stufe.
XP basiert auf agilen Werten und Prinzipien, die sich nicht wesentlich von denen anderer agiler Ansätze unterscheiden. Aber XP kommt – im Gegensatz zu Scrum oder Kanban – mit einem konkreten Satz von Praktiken der Softwareentwicklung, die die Software Delivery Performance erheblich steigert.
Pair-Programming und Test-first-Programming sind zwei der bekannteren XP-Praktiken.
Pair-Programming hebt die Zusammenarbeit unter den Teammitgliedern auf die nächste Stufe. Das bedeutet, dass alle Entwickler die meiste Zeit über in Paaren arbeiten. 2 Entwickler, 1 Computer, 1 Problem. Der kontinuierliche Verbesserungsprozess findet ständig statt. Ein Paar von Entwicklern tauscht ständig Wissen aus und gibt sich gegenseitig Feedback sowie Anleitung.
Test-first-Programming ist die Disziplin, Code in kurzen Zyklen von 5-15 Minuten zu entwickeln. Jeder Zyklus beginnt mit dem Schreiben eines Tests (der fehlschlagen wird), der Anpassung des Codes (damit der Test besteht) und der Verbesserung des Codes (um sicherzustellen, dass der Code wartbar bleibt).
Beim Test-first-Programming wird die Größe der Arbeitspakete praktisch auf weniger als eine Funktion zur gleichen Zeit reduziert. Jeder Test befasst sich mit einem der vielen Aspekte einer einzelnen Funktion. Jeder Test treibt den Einbau eines Features näher in zum Abschluss.
Zusammenfassung
Das Penny-Spiel zeigt, dass die Reduzierung der Arbeitspaketgröße zu kürzeren Feedback-Zyklen führt. Und kürzere Feedback-Zyklen haben einen tiefgreifenden Einfluss auf die Lieferzeit und die Qualität.
Agile Methoden versuchen, dasselbe für Softwareprojekte zu erreichen. Allen agilen Methoden ist gemeinsam, dass sie die Paketgröße reduzieren, um zeitiger Feedback vom Kunden zu erhalten. Um die Paketgröße zu verringern, fördern sie eine engere Zusammenarbeit aller Beteiligten, die daran arbeiten, ein Feature dem Kunden vorzustellen.
Scrum führt das Konzept von 4-wöchentlichen Sprints und funktionsübergreifenden Teams ein.
Kanban verwendet wöchentliche Iterationen und Begrenzungen für den Arbeitsfortschritt, die das Team zwingen, noch enger miteinander zusammenzuarbeiten.
Und eXtreme Programming (XP) bringt engere Zusammenarbeit und kürzere Feedback-Schleifen, durch Pair-Programming und Test-first-Programming, auf die Spitze.
Bis demnächst
-David