Markt und Produkte – Strömungsabriss im Feedbackzyklus

The number one reason for business screwups is the lack of a market need for a new product – Jurgen Appelo.

Eine Priorisierung ist nur eine Momentaufnahme. Die besten Produkte entstehen in der kontinuierlichen Zusammenarbeit mit Kunden. Egal welche Tools und Modelle man verwendet, es bleibt die Frage, wie häufig man dafür mit dem Kunden zusammenkommen sollte.

Agilisten zeigen gerne das Video vom Nordstrom Innovation Lab, um zu verdeutlichen, was agiles Arbeiten eigentlich bedeutet: Ein Entwicklungsteam setzt sich in die Filiale eines Optikers und entwickelt, in direkter Interaktion mit den Kunden, eine App zur Auswahl von Brillen. 

Stefan Roock von it-agile hat in seinem Beitrag über den Agilen Kernzyklus destilliert, was den Kern agiler Zusammenarbeit ausmacht:

Das Umsetzungsteam und der Endkunde arbeiten in möglichst direktem Kontakt. Der Problemlösungskreislauf zwischen ihnen ist so eng wie möglich. Je näher das Vorgehen an diesem Kernzyklus liegt, umso besser wird das Produkt wahrscheinlich den Bedarf des Kunden treffen. 

Nicht jedes Produkt lässt sich wie im Nordstrom Innovation Lab direkt beim Kunden entwickeln, aber oft reisst im Eifer der Entwicklung der Feedbackkanal zum Kunden komplett ab. Kommt man nur am Anfang eines Projektes mit dem Kunden zur Definition von Lasten- und Pflichtenheft zusammen, ist man maximal weit vom Kernzyklus entfernt. Es ist in diesem Fall fast zwangsläufig, dass gegen Ende des Projekts einige böse Überraschungen auf alle Beteiligten warten. Dinge wurden etwa falsch verstanden und nicht geklärt, die Bedürfnisse des Kunden haben sich verändert und/oder mögliche Synergien durch kurze Feedback-Zyklen wurden verschenkt.

Es gibt eine Reihe von Methoden, die Empfehlungen geben, wie man den Feedbackzyklus mit dem Kunden optimal ausgestaltet: Scrum fordert, dass man Mindestens einmal im Monat den Zyklus durchläuft und z.B. im Review ein Teilprodukt präsentiert und auf Basis des Feedbacks die Entwicklung anpasst. Als Framework gibt Scrum aber wenig Hinweise, wie genau die konkrete Ausgestaltung passieren soll (siehe Scrumguide).

Design Thinking oder kurz DT ist ein Ansatz für Produktdesign, der danach strebt, das Optimum aus dem Widerstreit von Kundenbedürfnisse und technischen Möglichkeiten herauszuholen. DT ist damit sehr nah am agilen Kernzyklus dran. Es gibt verschiedene Schulen des Design Thinking. Die d.school der Stanford University z.B. definiert 5 Schritte mit flexibler Reihenfolge:

1. Empathize: Interviews führen, Handlungen beobachten, Menschen in ihrem Kontext verstehen, Gedanken aussprechen, Gefühle offenlegen, Storys suchen
2. Define: Kernproblem synthetisieren, inspirierende Perspektive gewinnen, Kriterien für die Bewertung konkurrierender Ideen festlegen
3. Ideate: Raum der Lösungsmöglichkeiten aufziehen, so viele Ideen wie möglich generieren, Brainstorming, aussichtsreichste Ideen auswählen.
4. Prototype: schnelle, billige Prototypen bauen, die Antworten auf wichtige Fragen für die finale Lösung liefern können. Bsp.: Wand mit Post-its, Rollenspiel, Storyboard,  Bastelei
5. Test: Prototypen den Kunden zeigen und Feedback einsammeln.

Auch Lean Startup ist eine Vorgehensweise um Produkte zu bauen, die optimal auf Kundenbedürfnisse zugeschnitten sind. Im Gegensatz zu Design Thinking betrachtet es Produktentwicklung als strukturiertes Experiment, bei dem im wissenschaftlichen Sinne zuvor aufgestellte Hypothesen überprüft werden. Es gibt 3 Schritte:

1. Build: Ideen schnell in Produkte verwandeln
2. Measure: Reaktionen von Kunden messen
3. Learn: Strategie fortführen oder verändern (pivot)

Jurgen Appelo kombiniert wiederum Design Thinking und Lean Startup zum Innovation Vortex. Dieser “Wirbelsturm” dreht sich in der Geburtsphase eines Business Modells sehr schnell. Man hat bisher nur wenig Erkenntnisse über die Bedürfnisse des Kunden und arbeitet dicht am agilen Kernzyklus, um möglichst schnell seine Annahmen zu validieren. Je stärker das Produkt am Markt etabliert ist, umso langsamer dreht sich der Vortex. Man schmeißt nicht mehr bei jeder neuen Erkenntnis alles über den Haufen, muss mehr auf Bestandskunden, CI, die eigene angewachsene Organisation und andere entstandene Strukturen achten.

Fazit: Eine gute Produktentwicklung erfordert schnelles Feedback vom Kunden. Dieses sollte mindestens einmal im Monat, gerade am Anfang der Entwicklung aber tendenziell schneller passieren. Mit leichtgewichtigen Prototypen sollten die kritischen Hypothesen zum Produkt überprüft werden. 

Der Innovation Vortex ist übrigens Teil des Shiftup-Workshops, den ihr bei mir in Hamburg und demnächst auch online buchen könnt. Informationen dazu findet ihr hier: Shiftup-Workshop.

Literatur

Jurgen Appelo 2019: Startup, Scaleup, Screwup*: 42 Tools to Accelerate Lean and Agile Business Growth (English Edition): Wiley

Michael Lewrick 2018: The Design Thinking Playbook*: Mindful Digital Transformation of Teams, Products, Services, Businesses and Ecosystems: Wiley

Eric Ries 2011: The Lean Startup*: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses: Currency

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Lean/Kanban Games – Teil 2

Neben dem Push & Pull Game hat die Limited WIP Society Hamburg einige weitere Lean/Kanban Games gespielt, darunter das Name Game, das die Nachteile von Multitasking und Context Switches sichtbar macht:

Hier nur das Executive Summary:

1. Schreibe 5 Namen auf, alle gleichzeitig, d.h. erst alle ersten Buchstaben, dann alle zweiten usw. Miss wie lange es pro Name dauert und die Gesamtzeit.
2. Dann schreibe die 5 Namen nacheinander und miss wieder die Zeit.
3. Vergleiche die Ergebnisse und diskutiere

Ein ausführliche Beschreibung gibt es z.B. hier: LINK

Das Sixes Game soll die Auswirkungen von übertriebenen Sicherheitspuffern in Schätzungen von Projekten sichtbar machen. Auch dieses Spiel skizziere ich hier nur grob. Es gibt ein ausführliches Paper dazu: LINK

Jeder Teilnehmer übernimmt ein Teilprojekt, dessen Dauer davon abhängt, wann er mit einem 6-seitigen Würfel eine 6 würfelt. Für jeden Wurf dauert das Projekt einen Tag. In einem Testprojekt lässt der Moderator alle ein paar Mal würfeln, um ein Gefühl für die Wahrscheinlichkeiten zu kriegen.

Dann geht es los. Ein wichtiges Projekt für den besten Kunden steht an und die Spieler sollen sich auf eine Anzahl Tage einigen, die jedes Teilprojekt maximal dauert (MAX TAGE). Die dem Kunden kommunizierte Gesamtdauer beträgt dann:

PROJEKT GESAMTDAUER = ANZAHL TEILPROJEKTE * MAX TAGE

In dieser Runde dauert jedes Teilprojekt also mindestens MAX TAGE. Wenn nur ein Teilprojekt länger braucht, verlängert sich auch die Gesamtdauer.

In der Diskussion danach sollte die Gruppe feststellen, dass viele Spieler wesentlich früher fertig sind und Zeit geblockt haben, die sie eigentlich nicht brauchen. Die Frage ist, wie man die Projekte organisiert, damit einerseits genügend Puffer da ist, aber andererseits zuviel Pufferzeit nicht die Gesamtdauer übertrieben aufbläst.

Eine Lösung des Problems, mit 25% kürzerer Projektdauer bei 95% Erfolgswahrscheinlichkeit, kommt aus der Theory of Constraints: Die geschätzten Sicherheitspuffer werden für jedes Teilprojekt halbiert und die Hälfte der gestrichenen Summe für länger laufende Teilprojekte am Ende des Gesamtprojekts hinzugefügt. Wenn also die Schätzung mit Sicherheitspuffer für 10 Teilprojekte bei 16 Tagen liegt, gibt man den Projekten nur 8 Tage und fügt dafür am Ende (10*8)/2=40 Tage als Puffer für Teilprojekte im Verzug hinzu.

Die statistischen Hintergründe dazu findet man in dem genannten Paper.

Bei der Durchführung mit der Limited WIP Society, haben wir natürlich auch dieses 95% sichere Projekt gerissen – Murphy lässt grüßen ;-).

Push & Pull Game – Lean/Kanban Games Teil 1

Hafenblick, kühle Getränke, schöne Menschen – die limited WIP Society traf sich diesmal bei IT-Agile.

Das Thema waren Lean/Kanban Games und die möglichen Spiele füllten schnell das Board. Da die Beschreibung etwas länger geworden ist, teile ich sie in zwei Beiträge auf (Teil 2 HIER).

Papierboote falten als Push/Pull-Game 

Beim Push/Pull-Game geht es darum die Unterschiede von Push und Pull-Systemen sichtbar und fühlbar zu machen. Dabei übernimmt jeder Teilnehmer unterschiedliche Verarbeitungsschritte auf einer Art Fließband. Wir haben Papierboote gefaltet, aber beliebige Varianten sind denkbar (z.B. Cup Assembly).

Als Material braucht man:

• Einen großen Tisch
• einen großen Stapel weiße DINA4-Zettel
• ein paar gelbe DINA4-Zettel
• zwei Stoppuhren bzw. Smartphones mit Stoppfunktion

Wir waren 5 Spieler mit folgenden Schritten (bei mehr oder weniger Spielern, einfach die Schritte weiter aufteilen bzw. zusammenfassen):

1. Spieler: Papier vom Stapel nehmen, einmal in der Mitte falten und für den nächsten in der Mitte anfalzen
2. Beide Ecken umknicken, als würde man einen Flieger bauen wollen.
3. Unterkanten auf beiden Seiten nach oben klappen und die überstehende Ecke auf einer Seite nach innen umklappen, so dass ein Hut entsteht.
4. In den Hut greifen und zum Quadrat umklappen. Dann die unteren Ecken hochklappen und zum Schiff auseinanderziehen.
5. Der fünfte Spieler nummeriert die Boote und schreibt die Ankunftszeit auf. Achtung: Spieler 5 und der Moderator müssen zu Beginn synchron eine Stoppuhr starten.

Wem das zu wenig visuell ist, möge sich folgendes Video zu Gemüte führen:

Es lohnt sich übrigens, die Spieler einen Probelauf durchführen zu lassen, bevor es richtig losgeht!

Als erstes haben wir im Push-System gearbeitet, d.h. jeder Spieler hatte einen beliebig großen Puffer vor bzw. hinter sich. Nach wenigen Minuten hatten sich so zwischen einigen Spielern große Warteschlangen gebildet.

Nach 2:30 Minuten gibt der Moderator einen gelben Zettel in die Queue. Achtung: Wenn sich die Puffer sehr schnell füllen, lieber etwas früher den gelben Zettel hineingeben.

Ist der gelbe Zettel durch den Prozess durch, kann das Spiel gestoppt werden.

Am Ende sollte Spieler 5 eine Übersicht über die Ankunftszeiten erstellt haben:

In unserer Gruppe entwickelte sich der Durchsatz in Richtung 4 Schiffe pro Minute. Ich selbst war an Position 4 und hatte eine recht komplexe Aufgabe, so dass sich mit der vor mir anwachsenden Queue auch der gefühlte Druck erhöhte. Gerne gesehene Kommentare von den Spielern links und rechts waren: “Ach bei dem staut es sich ja wieder mal” oder “Den müssen wir auswechseln.” Sowas kommt in realen Projekten natürlich niemals vor ;-).

Als das Spiel gestoppt wurde hatten wir etwa ein Dutzend unfertige Schiffe als Waste in den Puffern liegen.

Dann haben wir die Pull-Variante gespielt. Hier ist der einzige Unterschied, dass jeder Spieler ein Pufferlimit von 1 hat, d.h. er darf erst mit dem nächsten Papier anfangen, wenn der auf ihn folgende Spieler seinen Zettel angenommen hat.

Nach kurzer Zeit wartete die gesamte Prozesskette darauf, dass ich mit meinem Schritt fertig wurde, was gefühlt noch schlimmer war, als nur die Queue anwachsen zu sehen.

Auch bei der Pull-Variante ging der Durchsatz auf ca. 4 Schiffe pro Minute zu.

Der Waste waren die 4 unfertigen Schiffe bei den vier Faltern.

Nun betrachteten wir die Durchlaufzeit anhand des gelben Schiffes in beiden Varianten. In der Push-Variante hatte das Schiff eine Durchlaufzeit von 1:53 Minuten, in der Pull-Variante nur 1:07, da es nicht in vollen Queues warten musste.

In der anschließenden Diskussion sprachen wir darüber, dass man im Pull-System die Slacktime natürlich statt für Nörgeleien dafür nutzen sollte den Teammitglieder zu helfen bzw. kreative Verbesserungsvorschläge zu erarbeiten, die den Engpass verringern.

Variante: einen zweiten gelben Zettel reingeben um zu zeigen, dass sich die Durchlaufzeit im Push-System mit der Zeit vergrößert.

Dank an Frank und Florian für Fotos und Ergänzungsvorschläge!

Das derzeit beste deutsche Kanban-Buch* wurde übrigens von Florian übersetzt.

Kurzbeschreibungen für Name Game und Sixes Game in Teil 2.