In diesem Artikel stelle ich die Lean Startup Methode vor. Ich kenne Lean Startup seit 2012, als während meiner Arbeit bei Acquica das Buch von Eric Ries die Runde machte. Lean Startup ist ein erfolgreiches Meme, deshalb als erstes zwei Begriffsdefinitionen: „Lean“ und „Startup“.
Das Wort lean in Lean Startup bedeutet nicht sparsam, sondern "schnell und ohne Verschwendung".
Ein Startup ist "eine Organisation mit dem Ziel, ein Produkt oder Service bei extremer Unsicherheit zu schaffen".
Wie gesagt, Lean Startup ist ein erfolgreiches Meme. Viele Begriffe, vor allem „Minimum Viable Product“ und „Continuous Deployment“, wurden in den allgemeinen Wortschatz übernommen.
Ich werde auf Pivots („Sternschritt“ im Basketball) hier nicht näher eingehen, sondern den Kernprozess von Lean Startup, den Build/Measure/Learn-Zyklus erklären, das Verhältnis von Agiler Softwareentwicklung und Lean zeigen und kurz zwei konkrete Techniken anreissen.
Dieser iterative Prozess bildet den Kern von Lean Startup. Ausgehend von Hypothesen zu Mehrwert und Wachstum definiert das Team ein minimales Produkt. Entscheidend ist nicht die Feature-Liste, sondern die Validierung der Hypothesen. Entsprechend liegt der Fokus in der Konzeption auf die integrierten Messinstrumente. Ein neuer Zyklus beginnt, wenn die Experimente ausgewertet und neue Hypothesen abgeleitet sind.
Hier ist der selbe Prozess abgebildet, statt was mit Fokus auf wer. Die Teams konzipieren Experimente und hat alle Möglichkeiten und Fertigkeiten, von Design über Page Creation, Programmierung, Deployment und Auswertung. Das Management investiert in Maschinerie für Live- und Testumgebungen und in Werkzeuge für Kohortentests und Split-Experimente.
Diese iterative Vorgehensweise deckt sich mit agiler Software-Entwicklung nach Scrum, oder? Scrum wird oft ebenfalls als Zyklus dargestellt, wie hier auf diesem Poster, unter dem ich zwei Jahre lang in Frankfurt gearbeitet habe.
Eric Ries zitiert zur Klärung der Beziehung zwischen Agiler Softwareentwicklung und Lean Startup W. Edwards Deming: "The customer is the most important part of the production line."
Ich möchte an dieser Stelle den Teil eines Vortrages von Eric Ries bei Google einflechten, in dem er den Unterschied zwischen Agile Software Development und dem Lean Startup Prozess erklärt.
Am Ende ist die wichtige Erkenntnis, dass Validated Learning Teil der Produktentwicklung werden muss. Teams beginnen dann, ihre Produktivität anhand von validiertem Lernen und nicht an ausgelieferten Features zu messen.
Agile Software Development schafft Effizienz bei bekanntem Problem. Eine Kurskorrektur ist "out of scope" des Prozesses. Die Lösung für diese Diskrepanz ist, Validated Learning in den Entwicklungsprozess zu integrieren. Typische Werkzeuge sind Split Tests und Kohortenanalyse.
Zur Veranschaulichung: Bei einer Atlantiküberquerung von Teneriffa nach Cape Canaveral / Florida bedeuten 5 Grad Abweichung vom Kurs, dass man sein Ziel um 600km verfehlt. Besser sind häufige, kleine Kurskorrekturen nach Positionsbestimmung. Bei neuen Geschäftsmodellen helfen Erfahrung und Kundenbefragungen bei der Bildung der anfänglichen Hypothesen. Einmal unterwegs, hilft nur messen.
Für Kurskorrekturen aus Feedback bei gleichzeitig maximierter Geschwindigkeit eignet sich ein Kanban-Prozess (Pull + Limit des „Work in Progress“). Features werden deployed, sobald sie fertig sind (Eine Taktik, hier bei guter Qualität schneller zu werden, stelle ich gleich mit dem Produkt-Immunsystem vor). Neue Features werden erst angegangen, wenn genügend Validierungsergebnisse vorliegen.
Hier ein Beispiel:
Das ist eine ganz wichtige Frage. Viele Mitarbeiter in etablierten Unternehmen werden diese Frage mit einem klaren "nein" beantworten. Inzwischen sind selbst Unternehmen mit rein digitalen Geschäftsmodellen so weit etabliert, dass sich Organisationsstrukturen und Arbeitsweisen entlang von Hierarchien und Prozessen ganz analog zur analogen Wirtschaft gebildet haben.
Aber betrachten wir noch einmal die Definition eines Startups: Hier geht es um neue Geschäftsmodelle in extremer Unsicherheit. Und plötzlich ist fast jedes Unternehmen betroffen! Es gibt zwar große Trends (Mobile Shift, Artificial Intelligence), aber die Zyklen werden derart kurz, dass auch in etablierten Unternehmen die die Geschäftsmodelle ständig anpassen müssen, um nicht nach kurzer Zeit obsolet zu werden.
Viele Unternehmen stecken mitten in einer Digitalen Transformation. Sie haben kleine autonome Teams eingeführt, betreiben Agile Software-Entwicklung und haben systematische Qualitätssicherung und Continuous Delivery eingeführt. Aber reicht das?
Was oft fehlt ist das Denken in digitalen Produkten. Dabei wird Produktentwicklung als Reihe von Experimenten verstanden, es werden Messungen geplant und diese dann ausgewertet. Der so ausgelöste Lernprozess wird per Kanban mit Work in Progress-Limit gesteuert. Auch geplante Pivots gehören dazu.
Hat man sich so auf die Reise gemacht, sind zwei Techniken aus dem Lean Startup Werkzeugkasten besonders hilfreich:
Continuous Deployment schützt die Produktentwicklung durch ein Immunsystem und ergänzt die Anstrengungen in der Softwareentwicklung entlang der Testpyramide um ein kontinuierliches Monitoring:
Die zweite Technik ist das "Fünf Warum" -Meeting:
Bei auftretenden Problemen wird ein 5W-Meeting mit allen Beteiligten (Management, Community Management, Betrieb) abgehalten. Erfahrenste Teilnehmer nehmen Fehler auf sich („Problem im Prozess“). Zur Moderation ist ein 5W-Master hilfreich. Eine kleine Variante versucht einfach, dasselbe Problem nicht zweimal auftreten zu lassen.