The Lean Startup

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.

Der Lean Startup Prozess

lean-startup-process

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.

Rollen

lean-startup-roles

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.

Welcher Agile Prozess passt?

scrum-poster

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.

lean-startup-validatedlearning

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.

lean-startup-atlantic

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:

lean-startup-kanban

Ist dein Unternehmen ein Startup?

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.

Der Transformationsprozess

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.

Continuous Deployment & Fünf Warum

Hat man sich so auf die Reise gemacht, sind zwei Techniken aus dem Lean Startup Werkzeugkasten besonders hilfreich:

  • Continuous Deployment durch ein Produkt-Immunsystem. Der Erfinder des Begriffes "Continuous Deployment", Timothy Fitz, war ein Kollege von Eric Ries bei IMVU.
  • Fünf "Warum" für adaptive Veränderung. Der Prozess der "Five Whys" hilft, eine Organisation anpassbar zu machen und nicht unnötige Zeit mit internen Optimierungen zu vergeuden.

Continuous Deployment schützt die Produktentwicklung durch ein Immunsystem und ergänzt die Anstrengungen in der Softwareentwicklung entlang der Testpyramide um ein kontinuierliches Monitoring:

  • Fehlerhafte Änderung wird sofort und automatisch entfernt
  • Jeder im betroffenen Team wird benachrichtigt
  • Keine weiteren Änderungen sind möglich bis die Wurzel des Problems gefunden und behoben ist

Die zweite Technik ist das "Fünf Warum" -Meeting:

  • Finden der Wurzel eines Problems
  • Oft steckt hinter einem technischen Problem ein Mangel im Prozess
  • Hilft beim Bau einer adaptiven Organisation
  • Proportionales Investment auf jeder der 5 Ebenen
  • dadurch schrittweise Verbesserung
  • Vorsicht vor den fünf Anschuldigungen

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.

Weitere Materialien