Flow in einem Lean Startup erreichen (Teil 1)

Die Eliminierung von Verschwendung ist ein fundamentales Prinzip des Lean-Denkens. Womak und Jones haben es in ihrem Buch Lean Thinking (ein Must-Read) so definiert:

Verschwendung ist jede menschliche Aktivität, die Ressourcen absorbiert, aber keinen Wert schafft.

Von allen Ressourcen ist keine so wertvoll wie Zeit. Zeit ist wertvoller als Geld. Während Geld nach oben oder unten fluktuieren kann, bewegt sich Zeit nur in eine Richtung – nach unten. Der Wert von Zeit für Lean Startups zeigt sich in Boyds Gesetz, das besagt:

Die Geschwindigkeit von Iterationen schlägt die Qualität von Iterationen.

Colonel John Boyd, ein Militärstratege und Air-Force-Kämpfer, fand das durch die Untersuchung einer Anomalie bei Dogfights heraus, in denen eine vermeintlich unterlegene Maschine (F-86) ständig eine vermeintlich überlegene Maschine (MiG-15) schlug, weil sie in der Lage war, schneller zu iterieren – dank eines hydraulischen Steuerknüppels gegenüber einem manuellen. Eric Ries wendet Boyds Gesetz auf Lean Startups an, indem er die Wichtigkeit hervorhebt, die Cycle-Time durch den Build-Measure-Learn-Kreislauf zu maximieren.

Build Measure Lean Cycle

Erfolgreiche Startups sind die, die es hinbekommen, oft genug zu iterieren, ehe ihnen die Ressourcen ausgehen. Die Zeit zwischen diesen Iterationen ist fundamental.

Die konkurrierende Zeitnutzung

Zeit hat (wie jede Ressource) mehrere Pulls. Dem Customer Development zufolge gibt es einen grundlegenden Pull für Aktivitäten außerhalb des Gebäudes gegenüber solchen innerhalb des Gebäudes. Steve Blank ("Get out of the building!") ist der Ansicht, dass alle Antworten außerhalb des Gebäudes zu finden sind, und tritt für den Aufbau eines cross-funktionalen Customer-Development-Teams ein, zu dem die Gründer gehören müssen. Was ist mit Arbeit, die im Gebäude getan werden muss? Wer macht sich daran, die Lösungen für Probleme zu implementieren, die außerhalb des Gebäudes aufgedeckt wurden?

Eric Ries' Antwort besteht darin, zwei Teams aufzustellen, die sich gegenseitig füttern: ein Problemteam und ein Lösungsteam. Das erste Team fokussiert sich auf Customer Development, das zweite auf die Produktentwicklung. Wenn Sie allerdings der Gründer sind, müssen Sie in beiden Teams sein, und darin liegt der fundamentale Planungs-Tauziehen.

Das Problem verstärkt sich noch, wenn Sie ein Gründer aus der technischen Ecke sind (wie ich), denn Zeit wird auf sehr unterschiedliche Weise genutzt, wenn man von der Produktentwicklung zum Customer Development kommt. Paul Graham hat ein exzellentes Essay über die beiden Arten der Planung geschrieben: Manager's Schedule and Maker's Scheduele. Manager organisieren ihren Tag typischerweise in Blöcke zu je einer Stunde, und sie verbringen jede Stunde mit einer anderen Aufgabe. Macher wie zum Beispiel Programmierer müssen ihren Tag in größere Blöcke einteilen, während derer sie nicht unterbrochen werden. In der Planung des Managers sind die Kosten für Kontextwechsel gering (und Kontextwechsel werden erwartet). In der Planung des Machers sind Kontextwechsel Produktivitätskiller und die Kosten hoch.

Aktivitäten außerhalb des Gebäudes (Kundeninterviews, Usability-Tests, Kunden-Support) tendieren dazu, auf der Agenda des Managers zu stehen, während Arbeiten innerhalb des Gebäudes (Design, Coding) in der Planung der Macher zu finden sind. Das Gleichgewicht zwischen diesen beiden Pulls zu finden, ist eher eine Kunst als eine Wissenschaft, doch es gibt ein fundamentales Prinzip, das präsent sein muss, um die Produktivität zu maximieren: Flow. Es gibt zwei verschiedene Definitionen dafür, was ich mit Flow meine, und beide treffen hier zu.

Die erste stammt von dem Psychologen Mihály Csíkszentmihályi, der Flow als ein mentales Funktionsstadium definiert, in dem man sein Bestes leistet. Wer im Flow ist, ist so vollständig in eine Aktivität vertieft, dass nichts anderes zählt. Man verliert Selbstwahrnehmung und Zeitgefühl.

Aktivitäten, die "fließen", haben normalerweise die folgenden Eigenschaften:

  • Man hat ein klares Ziel.
  • Man braucht volle Konzentration.
  • Es gibt keine Unterbrechungen und Störungen.
  • Es gibt klares und unmittelbares Feedback über den Fortschritt in Richtung Ziel.
  • Es gibt eine Art Herausforderung.

Während Flow sich nicht nach Belieben auslösen lässt, kann man Aktivitäten doch so arrangieren, dass sie Flow erlauben, was zugleich der zweiten Definition entspricht. Aus "Lean Thinking":

Wenn wir anfangen, über die Wege nachzudenken, essenzielle Schritte, um eine Aufgabe zu erledigen, so anzuordnen, dass ein stetiger, kontinuierlicher Flow ohne verschwendete Energie und ohne Stapel und Warteschlangen erreicht wird, ändert dies alles, inklusive der Art unserer Zusammenarbeit und der Werkzeuge, die wir nutzen, um die Arbeit zu erledigen.

Im zweiten Teil des Artikels zeigt der Autor, wie er selbst bei seiner Arbeit in Startups Voraussetzungen für Flow schafft.

Dieser Artikel wurde im Original am 8. Dezember 2012 unter dem Titel Achieving Flow in a Lean Startup von Ash Maurya veröffentlicht. Ash Maurya gehört zu den führenden Köpfen der internationalen Gründerszene und ist einer der renommiertesten Experten für Lean Startup und Customer Development. Seinen Weblog finden Sie unter http://practicetrumpstheory.com. Die Website seines Unternehmens Spark59 erreichen Sie unter http://spark59.com. Mehr Fachartikel bietet unser Lean-Special.

didit checklists for Atlassian Cloud. Präzision, Effizienz, Erfolg. Alles abgehakt. didit checklists for Atlassian Cloud. Präzision, Effizienz, Erfolg. Alles abgehakt. didit checklists for Atlassian Cloud. Präzision, Effizienz, Erfolg. Alles abgehakt.
ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar