Experimente treiben bahnbrechende Erkenntnisse sowohl in der Naturwissenschaft als auch bei unserer Adaption wissenschaftlicher Methoden als Entrepreneure voran:
Der Schlüssel zum Durchbruch liegt jeweils hierin:
Wenn unsere Hypothese nicht mit dem Experiment übereinstimmt, ist sie falsch. Es spielt keine Rolle, wir schön unsere Hypothese ist, wie klug wir sind, wer die Hypothese aufgestellt hat oder wie sie heißt... sie ist falsch.
– Richard Feynman
Aber obschon Experimente hocheffektiv für das Testen von Annahmen sind, reicht es nicht aus, Experimente einfach durchzuführen. Der Output unserer Experimente kann nur so gut sein wie die Qualität der einfließenden Annahmen. Darüber hinaus muss die Durchführung von Experimenten nicht automatisch zu neuen Einsichten führen. Viele Experimente falsifizieren einfach schlechte Ideen.
Das wirft die folgende Frage auf: "Woher kommen gute Hypothesen oder Ideen?" Die Antwort lautet, dass gute Ideen von überall her kommen können. Die Herausforderung ist natürlich, dass wirklich gute Ideen rar und oftmals zunächst nicht von schlechten Ideen unterscheidbar sind. Wir brauchen einen robusten Prozess, der es uns einerseits erlaubt, eine große Bandbreite von Ideen zu generieren, und uns andererseits schnell die guten von den schlechten Ideen trennen lässt.
Genau dafür ist der LEAN Sprint entwickelt worden.
Was ist der LEAN Sprint?
Wir haben LEAN Sprints erfolgreich intern in unserem Team und in mehreren Dutzend Entrepreneur-Teams sowohl in Startups als auch in großen Unternehmen angewendet. Wer aus dem Software- oder Designbereich kommt, hat höchstwahrscheinlich schon mit den Scrum-/Agile-Methoden zu tun gehabt. Obwohl LEAN Sprints stark von Agile und Scrum beeinflusst sind (und neuerdings auch von den Design Sprints von Google Ventures), gibt es doch einige wichtige Unterschiede.
1. Die Ziele sind andere
Das Ziel eines Scrum-Sprints besteht darin, Build Velocity zu demonstrieren. Das Ziel eines LEAN Sprints ist ebenfalls das Demonstrieren, aber nicht von Learning Velocity, sondern von Traction Velocity.
So, wie es nicht ausreicht, einfach ein tolles Produkt oder Feature zu bauen, ist es auch nicht genug, einfach Lernen ohne Business-Ergebnisse zu demonstrieren.
Statt auf die Stapel mit Interview-Notizen zu zeigen, zeigen wir besser auf die Zahl der Kunden (oder auf den nächstliegenden Proxy eines Kunden), die sich im Vergleich zur Vorwoche neu angemeldet haben. Nur wenn das Kundenwachstum (oder Traction) mit dem Gelernten korreliert, sind die Learnings anwendbar.
2. Die Beteiligten sind andere
Scrum und Agile sind typischerweise auf Entwickler zentriert. LEAN Sprints erfordern dagegen das komplette Team inklusive der internen und externen Stakeholder.
3. Timeboxen diktieren keine Build- oder Release-Kadenzen
Ich bin ein großer Fan davon, mit Zeitbeschränkungen (oder Deadlines) zu arbeiten, um Innovation voranzutreiben und Aktionen zu forcieren.
Um Großartiges zu erreichen, sind zwei Dinge nötig: ein Plan und nicht genug Zeit.
– Leonard Bernstein
Abgesehen davon bin ich nach wie vor ein Verfechter von Just-in-time-Techniken wie Kanban und Continuous Deployment/Delivery bei der Auslieferung von Kunden-Value. Und die beiden schließen sich einander nicht aus. Timeboxen in einen LEAN Sprint werden nur genutzt, um eine Entscheidung zu forcieren, und nicht, um den Release-Zyklus anzutreiben.
Im zweiten Teil des Artikels schauen wir uns an, wie ein LEAN Sprint aufgebaut ist.
