Innovation Accounting mit dem Lean Stack (Teil 2)

Anmerkung der Redaktion: Im ersten Artikel hat Ash Maurya erläutert, welche Bedeutung Innovation Accounting hat, und beschrieben, welche Rolle fehlgeschlagene Experimente in einem Startup spielen und warum Experimente falsifizierbar und "timeboxed" sein müssen.

Es ist schwer, im Hinblick auf Timeboxing-Experimente diszipliniert zu sein. Wir haben daher eine regelmäßige Reporting-Kadenz sowohl mit den internen als auch mit den externen Stakeholdern etabliert.

Eine regelmäßige Reporting-Kadenz etablieren

Wir nutzen drei verschiedene Standup-Meetings, wie sie nachfolgend beschrieben sind:

Daily Standup: Unsere Daily Standups sind um die Kommunikation der Fortschritte an individuellen Aufgaben und Blockern herum strukturiert. Wir nutzen ein separates Online-Taskboard außerhalb des Lean Stack, das in diverse Sektionen aufgebrochen ist (Swimlanes). Die meisten Aufgaben sind direkt mit Experimenten verknüpft, die gerade laufen. Andere sind genereller in Sektionen wie Bugfixes, Code Refactoring, Blog-Posts schreiben usw. gruppiert.

Weekly Standup: Unsere Weekly Standups sind um die Kommunikation der Fortschritte an aktuellen Experimenten und das Definieren neuer Experimente herum strukturiert. Wir beginnen am Validated-Learning-Board und arbeiten uns von rechts nach links den Weg zurück. Zunächst diskutieren wir Experimente, die komplettiert sind (sowohl erfolgreiche als auch nicht erfolgreiche), die ihre Timebox überschritten haben (abgelaufen) oder die blockiert wurden.

Jede dieser Diskussionen muss mit einer klaren nächsten Aktion enden:

  • Ist ein Experiment fehlgeschlagen, abgelaufen oder gefährdet, besteht die nächste Aktion darin, herauszufinden, warum das so ist. Wenn das gelungen ist, werden das entsprechende Startegy-Risks-Board und das Lean Canvas aktualisiert (gegebenenfalls) und wird ein Folgeexperiment definiert.
  • Ist ein Experiment vorbei, ist die nächste Aktion die, herauszufinden, ob das zugrundeliegende Risiko, das wir entschärfen wollten, komplett eliminiert ist. Wenn nicht, wird ein Folgeexperiment definiert.

Die Konversation bis hierher basiert gänzlich auf empirischem Lernen nach der additiven Regel für Experimente.

Zusätzlich verbringen wir auch ein bisschen Zeit damit, wiederkehrende periphere Kundenvorgänge und/oder Feature-Anfragen zu diskutieren. Das Level an "Kunden-Pull" wird schnell gegen unseren aktuellen Schlüsselmetriken-Fokus abgewogen und wir treffen eine Entscheidung, ob wir entweder eine Problem-Understanding-Initiative initiieren oder aber die Sache zunächst vertagen.

Eine bekannte Falle in einem Startup ist das Überschätzen der eigenen Ressourcen und das ständige In-Bewegung-Sein (zu viel bauen und/oder konstante Brandbekämpfung).

Der einzige Ort, an dem Arbeit und Bewegung dasselbe sind, ist der Zoo, wo die Leute dafür zahlen, die Tiere herumlaufen zu sehen. (Taiichi Ohno)

Um das zu vermeiden, sind wir bestrebt, Slack in unsere Planung einzubauen – und damit Raum für kontinuierliche Verbesserung. Wir bilden das mit Kanban ab, indem wir Work-in-Progress-Limits auf dem Validated-Learning-Board nutzen, um die Anzahl der gleichzeitig laufenden Experimente zu beschränken. Das zwingt uns darüber hinaus dazu, unsere nächsten Aktionen erbarmungslos zu priorisieren, sodass alles, was wir tun, additiv ist und mit unserem singulären Schlüsselmetriken-Fokus abgestimmt ist.

Monthly Standup: Unsere monatlichen Standups sind um die Kommunikation der gesamtgeschäftlichen Entwicklung herum strukturiert. Wir erstellen makrofinanzielle und Innovation-Accounting-Metriken nebst einseitigen Fortschrittsberichten (Lessons Learned) für den letzten Monat. Das ist unsere Version des Pivot-oder-Durchhalten-Meetings, wie es Eric in seinem Buch beschreibt.

Der Output aus diesem Meeting wird auch mit unseren Beratern geteilt, deren Feedback wir in unsere strategische Ausrichtung einfließen lassen.

A3-Denken

Während der Lean Stack bei der visuellen Kommunikation von Fortschritt gute Arbeit leistet, werden Zusammenfassungen auf Post-its der Komplexität des Experimentdesigns und der Fortschrittskommunikation nicht gerecht.

Um dieses Defizit zu beheben, habe ich mir eine weitere Seite aus dem Playbook von Toyota ausgeborgt – die A3-Reports.

Wie Sie inzwischen wahrscheinlich wissen, bin ich ein großer Fan von Eine-Seite-Formaten.

Der A3-Report ist das Eine-Seite-Format, das Toyota entwickelt hat, um Probleme zu lösen, Pläne zu beschreiben und Fortschritt zu kommunizieren. Der Name A3 kommt von dem internationalen Papierformat. (A3 ist zudem die maximale Papiergröße, die ein Faxgerät übermitteln kann.) Heute nutzt Toyota zwar A4-Zettel, aber der Originalname ist erhalten geblieben.

So sieht unsere Vorlage für Experiment-Reports aus:

Wenn wir vereinbaren, ein Experiment durchzuführen, wird das Experiment einem Owner zugewiesen. (Normalerweise ist das der Initiator.) Dieser beginnt, indem er die linke Seite des Reports ausfüllt. Wenn das Experiment voranschreitet, werden die Daten aus dem Experiment rechts eingetragen. Und wenn das Experiment endet, wird die Validated-Learning-Sektion mit einer klar spezifizierten nächsten Aktion befüllt.

Wir nutzen zusätzliche Variationen dieser einseitigen A3-Reports, um Initiativen für neue Features (MMFs), Riskien und den monatlichen Fortschritt (Lessons Learned) abzubilden.

Ich weiß, was Sie jetzt denken. Das ist viel zu viel Prozess für ein Lean Startup. Sicherlich wird das alles der richtigen Arbeit im Wege stehen.

Auch ich habe Aversionen gegen nutzlose Prozesse. Ja, es geht schneller, alleine im Kopf zu iterieren, aber ich kann Ihnen aus erster Hand berichten, dass es schwer ist, den Ansatz der "mentalen Sprünge" über die Zeit hinweg zu skalieren – speziell in Teams mit mehr als zwei Leuten.

Der A3-Report ist weniger eine Vorlage als ein Weg, das Denken zu kristallisieren und zu visualisieren.

Wie das Lean Canvas lädt auch der A3-Report vermeintlich dazu ein, viel hineinzuschreiben, aber die Beschränkung auf eine Seite erzwingt ein Maß an Prägnanz, das dazu führt, dass all der Lärm hinten runter fällt.

Das Format selbst ist im Deming-PDCA-Kreis (Plan, Do, Act, Check) verwurzelt, der eine Menge Parallelen zum Build-Measure-Learn-Kreislauf und zum Meta-Iterationsmuster hat.

A3-Reports können zu sehr hilfreichen Archiven werden. Wir verfolgen mit diesen Reports nicht nur das Ziel, unser gegenwärtiges Denken zu kristallisieren, sondern wollen mit ihnen auch eine zugängliche Quelle mit archivierten Learnings für die zukünftige Nutzung etablieren.

Die Möglichkeit, Experimente mithilfe dieser Reports nochmals durchzuspielen, ist prima, um neue Teammitglieder mit unseren Learnings vertraut zu machen, und hilft uns, den Modus Operandi unserer Arbeit und unseres Denkens zu demonstrieren.

Überführung in die Praxis

In meinen einführenden Artikeln zum Lean Stack habe ich beschrieben, warum und wie wir das Lean-Stack-MVP in Form physischer Poster implementiert haben. Ich bin nach wie vor ein großer Befürworter einer physischen Card Wall. Die Card Wall dient als effektive Fortschrittsanzeige (auch aus etlichen Metern Entfernung) und fördert großartige Diskussionen.

Doch die größte Herausforderung war die, die Card Wall über unser räumlich verteiltes Team hinweg synchronisiert zu halten. Wir brauchten eine Online-Lösung und versuchten, eine mit bestehenden Web-Kanban-Tools zusammenzuschustern. Aber alle fielen durch – vor allem wegen des Mangels an Swimlanes.

Am Ende kamen wir mit einer einfachen und eleganten Lösung daher, die wir aus Keynote und Dropbox gebaut hatten und die unsere Anfangserwartungen deutlich übertraf.

Das geteilte Keynote-Dokument enthält die Master-Templates für alle Lean-Stack-Boards und A3-Reports. Das Hinzufügen und Bewegen von Karten auf den Boards funktioniert kinderleicht per Drag & Drop. Mithilfe von Hyperlinks waren wir in der Lage, einfach eine Klicknavigation zu bauen, die dazu führt, dass sich das Dokument wie eine App im Präsentationsmodus verhält. Aber der größte Vorteil ist der, alles in einem einzigen portablen Dokument abzubilden. Dieses Dokument haben wir Spark59 Playbook genannt, weil es Vision, Strategie und die laufenden Produktexperimente an einer Stelle vereint.

Wie die Poster haben wir auf unser Playbook-Template im Rahmen des Early-Access-Programms zugänglich gemacht und mit Videoinhalten und einer Einführung angereichert, die Ihnen die Evolution des Lean Stack nahe bringt. Hier gibt es Details.

Dieser Artikel wurde im Original am 25. September 2012 unter dem Titel How We Use Lean Stack for Innovation Accounting 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 www.ashmaurya.com. Die Website seines Unternehmens Spark59 erreichen Sie unter http://spark59.com. Mehr Fachartikel bietet unser Lean-Special.