Nicht jedes Team ist in der Lage, das, was es in einem Scrum-Sprint fertiggestellt hat, auch direkt an den Kunden auszuliefern. Es gibt eine Vielzahl von Gründen, warum es feste Release-Zyklen gibt und Updates für Kunden beispielsweise nur einmal im Vierteljahr erfolgen. In solchen Fällen kann es für eine Organisation sinnvoll sein, die Customer Cycle Time des Evidence-Based Management zu nutzen.
Was misst die Customer Cycle Time?
Die Customer Cycle Time misst die Zeit, die benötigt wird, bis ein neues Feature vom Kunden genutzt werden kann, nachdem damit begonnen wurde, es herzustellen.
Damit ist die Customer Cycle Time immer dann sinnvoll, wenn Deine Organisation in Release-Zyklen arbeitet und Scrum Teams nicht nach jedem Sprint ein Update (oder noch früher) an ihre Kunden und Nutzer ausliefern. Wenn wir einmal die Time-to-Learn-Phasen dazu zu Rate ziehen, dann ist der Unterschied in der Delivery-Phase zu entdecken.
Scrum Teams, die direkt nach jedem Sprint neue Updates ausliefern, würden die Phasen Build und Delivery als Doing betrachten. Sobald der Kunde ein neues Feature nutzen kann, zählt es als Done. Scrum Teams, die zwar in Sprints arbeiten, aber deren Updates mit einem festgelegten Release-Zyklus veröffentlicht werden, würden nur die Phase Build als Doing betrachten und alle Features, die in die Delivery-Phase übergehen bereits als Done.
| Time to Learn Phasen (Features) | Sketch (Idea) | Build | Deliver | Use | Learn |
|---|---|---|---|---|---|
| Status (Delivery direkt nach Sprint) | To Do | Doing | Doing | Done | Done |
| Status (Delivery in Release-Zyklen) | To Do | Doing | Done | Done | Done |
Durch die festen Releases ergibt eine Customer Cycle Time Sinn, wenn Du wissen möchtest, wie lange Deine Organisation benötigt, Nutzen zum Kunden zu bringen.
Einsatzbeispiel Customer Cycle Time
Ein Team benötigt im Durchschnitt 5 Wochen, um mit der Arbeit an neuen Features zu beginnen und liefert diese regelmäßig nach 2 Wochen fertig ab. Allerdings arbeitet die Organisation mit vierteljährlichen Release-Zyklen. Übertragen auf die Time-to-Learn-Phasen bedeutet das also:
| Time to Learn Phasen (Features) | Sketch (Idea) | Build | Deliver |
|---|---|---|---|
| Zeit pro Phase | 5 Wochen | 2 Wochen | 3 Monate |
Mit Hilfe der Customer Cycle Time kannst Du nun sichtbar machen, dass es trotz einer niedrigen Lead & Cycle Time (7 bzw. 2 Wochen) ziemlich lange dauert, bis der Nutzen auch beim Kunden ankommt, nämlich 3,5 Monate.
| Time to Learn Phasen (Features) | Sketch (Idea) | Build | Deliver |
|---|---|---|---|
| Cycle Time | 5 Wochen | 2 Wochen | 3 Monate |
| Customer Cycle Time | 5 Wochen | 3,5 Monate | |
| Lead Time | 7 Wochen | 3 Monate | |
Die Customer Cycle Time kann damit sehr hilfreich sein, um Probleme einer Organisation sichtbar zu machen, die nicht in “langsamen Teams” begründet sind, sondern in der Fähigkeit, den Nutzen auch zum Kunden zu bringen. Ein recht häufiger Reflex, wenn Kunden ausbleibende Updates bemängeln, ist es nämlich, die Arbeit in den Teams zu beschleunigen. Wenn sich aber der wahre Grund an anderer Stelle im Unternehmen befindet (nämlich in einer langen Delivery-Phase), kannst Du diesen Umstand sicht- und vor allem diskutierbar machen.
