Die Forscher konnten nachweisen, dass es sich nicht nur um Korrelationen handelt, sondern dass die Beziehungen „predictive“ sind. Wenn ich also Fähigkeiten habe, die am Pfeil-Beginn sind, dann sagt das Modell voraus (oder gibt einen Forecast), dass ich die Fähigkeit/das Ergebnis am Pfeil-Ende bekomme.
Eine häufig zitierte zentrale Fähigkeit ist die Software Delivery Performance (SDP). Sie wird gemessen anhand dieser Metriken:
- Wie häufig werden Releases durchgeführt?
- Wie lange dauert es, Releases durchzuführen?
- Wie häufig müssen Releases rückgängig gemacht oder hinterher gefixt werden? Wie lange dauert das?
Die SDP ist einer der Motoren agiler Entwicklung. Um die SDP zu stärken, brauche ich Fähigkeiten aus den Bereichen Management, Prozess, Kultur und insbesondere auch aus der Technik. Das oberste Prinzip des Agilen Manifests („…satisfy the customer through early and continuous delivery…“) ist damit nachweislich ein wichtiger Treiber für den Erfolg!
Es gibt einen selbstverstärkenden positiven Zyklus: Hat man die Fähigkeit einer hohen Software Delivery Performance, dann wirkt sich das rückwirkend wiederum auf die Fähigkeiten im Bereich Lean Product Development aus. Mit kürzeren Release-Zyklen kann man auch in viel kürzeren Zyklen und kleineren Batches Experimente am Markt fahren. Dadurch entsteht eine andere Kultur der Zusammenarbeit, die sich wiederum auf die Auslieferperformance auswirken kann.
Wie das Modell in einem Team anwenden?
Die Studienergebnisse liefern ein wichtige praktische Eigenschaften, die man zur Unterstreichung der Sinnhaftigkeit von Maßnahmen verwenden kann. Damit hat man für Diskussionen gute Argumente:
- Sie zeigen die Abhängigkeiten von Prozess, Kultur, Identität, Management und Technik auf.
- Schnell verständlich für alle Mitarbeiter im Unternehmen
- Die Studie liefert Metriken zur Messung aller Fähigkeiten
- Erfolg lässt sich mit Metriken messen statt mit Bauchgefühl
Ein erster einfacher Schritt ist die Software Delivery Performance zu ermitteln. Dazu kann man zwei Fragen stellen: „Wie häufig releast ihr? Und wie lange dauert das?“. Durch die erste Frage lässt sich sofort ein guter Überblick schaffen, wie es wohl um die Batch-Size und das Management der Features bestellt ist. Die zweite Frage schafft einen allerersten Eindruck davon, wie es um die Architektur des Systems und die Automatisierung der Delivery Pipeline und Tests steht.
Mit diesem Wissen hat Andreas Havenstein schon mehrere Workshops für Teams durchgeführt und dabei das komplette Modell als Grundlage genutzt. Wir möchten hier als Beispiel ein Team aus einem Handelskonzern genauer betrachten. Die genannten Details sind recht typisch und fallen uns immer wieder in Teams auf.
Die Teilnehmer konnten ziemlich schnell identifizieren, wo bei ihnen in den Kausalketten Probleme liegen. Für die als problematisch identifizierten Lücken wurden dann Metriken ausgewählt, die als „Leading Indicators“ für Verbesserungen genutzt wurden.
In Orange sind die Stellen markiert, die im Brainstorming als problematisch oder zu hinterfragen angesehen wurden:
