Warum Time to Learn eine hilfreiche Metrik ist
Organisationen, die mit einer hohen Komplexität in ihrem Markt oder Branche konfrontiert sind, sehen sich einem grundsätzlichen Problem gegenüber. Denn sie wissen nicht, ob das, was sie aktuell unternehmen, wirklich den gewünschten Effekt erzeugt.
Output vs. Outcome
Diese und andere Fragen laufen darauf hinaus, dass es einen grundsätzlichen Unterschied zwischen Output und Outcome gibt. Während ein potenzielles neues Feature der jeweilige Output ist, bleibt unklar, ob dieser Output tatsächlich das gewünschte Ergebnis (Outcome) erzeugt. Je höher die Komplexität in einer Branche ist, desto größer ist die Kluft zwischen Output und Outcome.
Jedes neue Feature ist eine Hypothese
Hypothesen helfen Deinem Scrum Team und Deiner Organisation dabei, eine Brücke über die oben erwähnte Kluft zwischen konkretem Output und gewünschten Outcome zu schlagen. Eine solche Hypothese könnte beispielsweise lauten:
Wir glauben, dass unser neues Produkt-Feature (Output) die Zufriedenheit unserer Nutzer (Outcome) steigern wird. Wir wissen, dass diese Hypothese wahr ist, wenn unser Net Promoter Score um 10 Punkte ansteigt.
Die relevante Frage, die sich jedoch neben der Hypothese selbst stellt, ist: Wie lange benötigt eine Organisation (oder ein Scrum Team), um das herauszufinden? Denn je schneller eine Organisation hinzulernen kann, desto früher ist sie in der Lage, auf Erkenntnisse zu reagieren und ihren Kurs anzupassen.
Die 5 Phasen der Time to Learn
Die Metrik Time to Learn bemisst die Zeit, die eine Organisation (oder Team) benötigt, eine Hypothese zu bestätigen oder zu widerlegen.
T2L gehört zur Key Value Area Time to Market des EBM-Frameworks und wird in Peter Konings Buch Agile Leadership Toolkit vorgestellt. Im Grunde ist sie den beiden Kanban-Metriken Lead Time & Cycle Time sehr ähnlich und lässt sich deshalb auch sehr einfach mit Kanban kombinieren. Dazu unterteilt Time to Learn den Workflow, den ein Feature durchlaufen musst, um eine aufgestellte Hypothese zu validieren, in 5 aufeinander folgende Phasen.
Beispiel für einen Time-to-Learn-Zyklus
Stell Dir vor, Dein Scrum Team liefert zwar alle zwei Wochen ein fertiges Update für sein Produkt, aber Deine Organisation aktualisiert die Software beim Kunden nur einmal im halben Jahr. (Weil der Prozess aktuell sehr aufwändig und risikoreich ist, sind Deine Kunden ebenfalls eher zögerlich, was Updates angeht.) Die Auswertung der Nutzung erfolgt durch Umfragen per E-Mail, aber es dauert meist zwei Monate, bis ausreichend Feedback zusammenkommt. Das gesamte Feedbacks wird dann in einem Meeting präsentiert, das nur einmal im Monat stattfindet.
Auf diese Weise kommst Du auf eine Time to Learn von 9,5 Monaten:
Ein flexibles Reagieren auf neue Bedingungen und Erkenntnisse ist für eine Organisation in diesem Zustand nahezu unmöglich. Denn obwohl die reine Umsetzung eines Features durch kurze, zweiwöchige Sprints erfolgt, dauert es trotzdem extrem lange, bis überhaupt klar ist, welche Auswirkungen ein Update wirklich hat.
Der größte Hebel für diese Organisation bestünde in diesem Fall nicht darin, noch mehr Features pro Sprint zu entwickeln, sondern die Updatezyklen bei seinen Kunden radikal zu verkürzen.
Visualisierung der T2L mit dem Validated Learning Board
Um die Metrik Time to Learn in der Praxis regelmäßig zu messen, kannst Du mit Deinem Team auf ein Validated Learning Board zurückgreifen. Dabei handelt es sich um ein simples Kanban Board, auf dem die fünf T2L-Phasen als Workflow visualisiert werden.
Jedes Feature bzw. jede Hypothese durchläuft dann diesen T2L-Workflow, sodass auf diese Art und Weise ein guter Überblick darüber entsteht, wie schnell Deine Organisation hinzulernen kann und welche Feature-Hypothesen sich derzeit in Arbeit befinden.
Das Validated Learning Board bietet deshalb eine interessante Alternative, den Workflow für Produkt-Features zu organisieren.
Sofern Dein Team ein digitales Kanban-Board wie zum Beispiel AzureDevops oder Jira verwendet, seid Ihr sogar in der Lage, die Time to Learn für Features automatisch zu ermitteln. Dazu müsst Ihr lediglich klar definieren, wo der Workflow beginnt und wo er endet, damit die Metrik berechnet werden kann.
Fazit zur Time-to-Learn-Metrik
Alles in allem ist Time to Learn meiner Meinung nach eine extrem hilfreiche Metrik für Organisationen.
Denn durch T2L kann eine Organisation nicht nur erkennen, wie lange sie braucht, um hinzuzulernen, sondern auch verstehen, an welcher Stelle des Workflows das größte Verbesserungspotenzial schlummert.
Sehr häufig liegen die Gründe für Verzögerungen nämlich nicht in zu langsam arbeitenden Scrum Teams begründet, sondern in allen nachgelagerten Prozessschritten des Workflows.
