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.
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.
| Durchlauf | Hypothese | Experiment | Kriterium |
|---|---|---|---|
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
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