5 1 Stimme
Artikel-Rating

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 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 in komplexen Umgebungen ist nicht vorab bestimmbar, ob diese Funktionalität 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.

Ich will anders arbeiten!

Agiles Produktmanagement mit Scrum, Kanban, EBM & OKR

Du möchtest Scrum in Deinem Unternehmen oder Deinem Team einführen, weißt aber nicht wie Du vorgehen sollst? Du hast von Kanban gehört, weißt aber nicht, wo Du starten solltest? Du möchtest Dein Unternehmen mit Objectives & Key Results agiler machen? Du möchtest Evidence-Based Management dazu verwenden, um komplexen Herausforderungen zu begegnen? Wir beraten Dich gerne!

Ich will anders arbeiten!

Die 5 Phasen der Time to Learn

Die Metrik Time to Learn (T2L) 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 Key Value Area Time-to-Market. Im Grunde basiert sie auf der sogenannten 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 Time to Learn in insgesamt 5 Phasen: