Datenschutzeinstellungen
😲Mein erstes Treffen mit The Lean Startup

😲Mein erstes Treffen mit The Lean Startup

Ich habe The Lean Startup kennengelernt, als ich im Projektmanagement Fragen hatte, warum Projekte erfolgreich sind und andere nicht.

Stefan Harms

TLDR; Mit der build-measure-learn-Methode aus The Lean Startup wird ein erfolgreiches Projekt analysiert und erklärt, warum dieser Erfolg nicht auf Folgeprojekte übertragbar war.

Wie bin ich eigentlich zu den Themen Innovation, New Work und agile Organisationen gekommen?

In meinen Projekten stellte sich 2012 die Frage, was ist eigentlich ein erfolgreiches Projekt. Und weiter: was unterscheidet ein erfolgreiches Projekt von einem nicht erfolgreichen Projekt.

Wir hatten ein hartes Projekt kurz vor dem Abschluss, wir hatten viel gelernt und auch Neuland betreten. Jetzt wollten wir den Erfolg auch auf die Nachfolgeprojekte übertragen. Und so die Erfolgswelle einfach weiter reiten. Das hat nur zum Teil so funktioniert. Wir haben drei Nachfolgeprojekte gleichzeitig gestartet: ein erste Projekt lief richtig gut, das zweite noch ganz in Ordnung und das dritte lief ganz katastrophal: warum?

Alle Projektleiter hatten im alten, erfolgreichen Projekt mitgearbeitet. Die Prozesse waren gleich und die Produkte vergleichbar. Daran konnte es nicht liegen.

The Lean Startup in a very small nutshell

Seit 2010 arbeitete Eric Ries als Berater für Startups und dokumentierte das in seinem Blog startup-lessons-learned. Seine Erfahrungen und seine Lessons Learned veröffentlichte er dann 2011 in seinem Buch "The Lean Startup*". Darin legte er seinen neuen Ideen dar und startete nebenbei die "The Lean Startup"-Bewegung, die auch noch nach zehn Jahren sehr aktiv ist und immer noch großen Einfluss auf die Startup-Bewegung hat.

Der wichtigste Punkt ist das Modell des "Build-Measure-Learn"-Zyklus, den Eric sich aus der wissenschaftlichen Methode entlehnt hat. Er beschreibt wie als Startup in einer frühen Phase arbeiten sollte.

icon
Helena und Pierre haben eine Geschäftsidee: Valet CarWash. Sie holen die Fahrzeuge beim Besitzer, fahren zur Autowäsche und waschen die Fahrzeuge und liefern sie wieder beim Besitzer ab. Bevor sie Geld investieren, wollen Sie prüfen, ob die Idee funktionieren könnte. Ihre Hypothese ist "Autobesitzer wollen lieber Zeit sparen, als sich bei der Waschanlage anzustellen." Um die Hypothese zu überprüfen, denken Sie sich folgendes Experiment aus: sie verteilen Rabatt-Flyer an der Autowaschanlage für ihre Dienstleistung an einem sonnigen Samstag. (build) Anhand der Kundenrückmeldung erfahren Sie, wie hoch die Bereitschaft ist, dass Kunden ihre Dienstleistung nutzen. (measure) Damit sie sich nicht selbst belügen, setzen sie sich das Kriterium, das 30% der potentiellen Kunden, das Angebot annehmen. Wenn Sie darunter liegen, müssen Sie ihre Idee anpassen, wenn sie darüber liegen, dann können Sie weiter machen. (learn)

Das Ziel ist validierte Informationen über den Kunden. Dies ist die Währung von Lean Startup.

The Lean Startup als Methode im Projektmanagement

Zurück zu meinen Projekten aus dem ersten Teil und analysieren wir die vier Projekte noch einmal genauer und betrachten sie mit einer "Lean-Startup-Brille". Wir haben gelernt, dass das bessere Verstehen des Kunden ein Projekt weiterbringt.

Im erfolgreichen Muster-Projekt haben wir als Team zusammen herausgefunden, wie unser Projekt funktioniert. Die Ingenieure hat sich um die Entwicklung der Regelalgorithmen gekümmert und wir haben iterativ die Algorithmen in Software übersetzt.

Unser erster Versuch bestand aus manueller Arbeit: ein Mensch braucht circa zehn Tage und dann ist die Software so gut es eben in der Zeit geht fertig. Damit konnten wir die ersten Durchläufe bedienen. Eric Ries hätte dazu gesagt, dass wir die Hypothese "unsere Ingenieure wollen den Job Software erstellen einkaufen" bestätigt haben. Das Experiment war: ein Software-Ingenieur übersetzt manuell die Algorithmen in Software. Unser Kriterium war die Akzeptanz der Kunden und die Fehlerrate.

Den im nächsten Schritt mussten wir mit den unvermeidbaren Fehlern, die Menschen machen umgehen. Denn die Akzeptanz für Fehler ist gesunken, so dass einfache Fehler große Eskalationen nach sich zogen.

Im Startup-Sprech haben wir ein Pivot durchgeführt, unser Geschäftsmodell hat sich von manueller zur automatischer Erstellung der Software gedreht. Und damit auch die Hypothese angepasst, dass unsere Kunden auch in begrenztem Umfang Aufgaben selbst übernehmen, damit die Software-Erstellung automatisiert werden kann und damit schneller wird. Das Experiment war ein Prototyp, der die Vorbereitung schon vorsah und der dann automatisiert die Software erstellt. Als Kriterium wurden die niedrigere (und konsistentere) Fehlerrate und die Dauer der Softwareerstellung genutzt.

Build-Measure-Learn-Zyklen

DurchlaufHypotheseExperimentKriterium
1

unsere Ingenieure wollen den Job Software erstellen einkaufen

ein Software-Ingenieur übersetzt manuell die Algorithmen in Software

Akzeptanz der Kunden

2

Kunden übernehmen Vorbereitung der Algorithmus selbst für kürzere Dauer

Prototyp übernimmt automatisierte Software-Erstellung

Dauer < 2h

Diese Zyklen sind nicht alle, die wir durchlaufen haben, nur die positiven Beispiel. Wir haben Hypothesen nicht bestätigt und im fehlenden methodischen Wissens haben wir falsch reagiert und entgegen des Wissensgewinns auf unserer Annahme beharrt. Im Rückblick auf das Projekt ist es erfolgreich, weil wir wenig vorgefertigte Annahmen hatten und uns an die Maxime gehalten haben: "probier was aus, wenn es funktioniert, bleib dabei". Der Fortschritt im Projekt hat sich mit jedem Durchlauf der build-measure-learn-Zyklus gefestigt und beschleunigt. Und ein Projekt ist dann erfolgreich, wenn es Ergebnisse produziert und das haben wir gemacht.

Learnings im Projekt

Damit kann ich die erste Frage beantworten

icon
Was macht ein Projekt erfolgreich? Ein erfolgreiches Projekt erzeugt stetig mehr Verständnis, wie der Kunde das Ergebnis einsetzen will und wie man am das Ergebnis erreicht (und hält sich auch daran).

Und die Antwort auf die zweite Frage ergibt sich daraus ganz natürlich. Unsere Annahme, dass man Projekterfolg kopieren kann, ist falsch. Denn wir haben uns nicht an den Kunden und deren gewollten Ergebnissen "entlanggehangelt", sondern unser Verständnis vorausgesetzt. Je nachdem wie ähnlich das Verständnis der Kunden und unser Verständnis, desto besser kann es funktionieren. Aber das gemeinsame Hiniterieren auf eine Lösung eines Problem fand nicht statt.

* Affiliatelink / Werbelink

Photo by Andre A. Xavier on Unsplash

ImpressumDatenschutzerklärung