Die meisten Scrum Teams arbeiten in einer Umgebung, die es ihnen nicht ermöglicht, frühzeitig Feedback darüber zu erhalten, ob das, was sie fertiggestellt haben, wirklich einen Nutzen beim Kunden stiftet. Mit Time to Learn (abgekürzt auch T2L) misst Du, wie lange Deine Organisation wirklich benötigt, um eine aufgestellte Hypothese zu validieren und daraus zu lernen.
Jedes neue Feature ist eine Hypothese
Der Grundgedanke des agilen Arbeitens mit Scrum besteht darin, in kurzen Iterationen ein fertiges Increment an Kunden zu liefern und durch die Nutzung der Anwender herauszufinden, ob eine neue Funktionalität tatsächlich einen Mehrwert darstellt. Denn Komplexität sorgt dafür, dass nicht vorab bestimmbar ist, ob eine neue Funktion tatsächlich die gewünschte Wirkung hat.
Jede Aktualisierung oder Erweiterung Deines Produktes ist deshalb im wahrsten Sinne des Wortes ein Experiment, mit dem Du eine von Dir aufgestellte Hypothese validierst. (Und hierbei ist eine widerlegte Hypothese genauso wertvoll wie eine bestätigte.) Eine solche Hypothese könnte etwa lauten:
Mit Feature XY senken wir die Zeit für Aufgabe ABC für den Nutzer um DEF Sekunden und steigern dadurch den NPS-Wert um 10 Prozent.
Diese Hypothese fokussiert sich voll und ganz auf Deine Nutzer. Und so kann sie auch nur dann bestätigt oder widerlegt werden, wenn Du weißt, ob Dein neues Feature überhaupt genutzt wird. Und falls ja, senkt sie den Zeitaufwand für Deine Nutzer wirklich um die von Dir anvisierte Zeit? Ist ein geringerer Zeitaufwand tatsächlich das, was Deinen Nutzern wichtig ist und somit seine Zufriedenheit steigert?
Arbeiten in Sprints, ohne hinzuzulernen
Die meisten Scrum Teams befinden sich in einem Kontext, der die Validierung ihrer Hypothesen extrem stark verzögert. (Manchmal sogar komplett verhindert.) Zwar arbeiten sie in zweiwöchigen Sprints, die sie auch regelmäßig gut abschließen, aber ihre fertiges Increment wird gar nicht zeitnah an Kunden ausgeliefert. Und falls doch, werden die Ergebnisse eines Updates beim Kunden nicht gemessen. Bestenfalls landet Feedback von Kundenseite an einer anderen Stelle im Unternehmen und erreicht weder Developer noch Produkt Owner rechtzeitig. Die Sprint Review wird nicht von “echten Kunden” besucht, sondern lediglich von internen Stakeholdern, die der Meinung sind, schon genau zu wissen, was der Kunde wolle.
Organisationen und Unternehmen verschenken damit wertvolle Zeit. Denn sie erkennen erst sehr spät, welche Auswirkungen das, was sie tun, beim Kunden hat.
Die 5 Phasen der Time to Learn
Die Metrik Time to Learn geht auf Peter Koning zurück und macht den oben genannten Umstand für Deine gesamte Organisation sicht- und vor allem messbar. Innerhalb des Frameworks Evidence-Based Management gehört Time to Learn zur sogenannten Key Value Area Time-to-Market. Im Grunde basiert sie auf der bekannten Lead Time, die Du vielleicht schon aus dem Lean Management oder Kanban kennst, spannt den Bogen jedoch noch weiter bis zu dem Zeitpunkt, an dem ein Team Feedback über die Nutzung ausgewertet hat. Koning gliedert die T2L in insgesamt 5 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 aufwändig und risikoreich ist, sind Deine Kunden ebenfalls eher zögerlich, was Updates angeht.) Die Auswertung der Nutzung erfolgt durch E-Mail-Umfragen, aber es dauert meist zwei Monate, bis ausreichend Feedback zusammenkommt. Das gesamte Feedbacks wird dann in einem Meeting präsentiert, dass nur einmal im Monat stattfindet.
Damit kommst Du auf eine Time to Learn von 9,5 Monaten. ( 2 Wochen für die Umsetzung, 6 Monate pro Auslieferung, 2 Monate für die Nutzungs-Auswertung und 1 Monat Lernen)
Ein flexibles Reagieren auf neue Bedingungen und Erkenntnisse ist für Deine Organisation in diesem Zustand nahezu unmöglich. Obwohl die reine Umsetzung durch kurze, zweiwöchige Sprints erfolgt, dauert es extrem lange, bis überhaupt klar ist, welche Auswirkungen ein Update wirklich hat. Der größte Hebel für Deine Organisation bestünde in diesem Fall nicht darin, noch mehr Features pro Sprint zu generieren, sondern die Updatezyklen bei Deinen Kunden radikal zu verkürzen. Auch eine automatisierte Messung der Softwarefeatures (etwa durch einen Usage Index), kann weitere Zeit sparen.
