On Lean and Agility

Ich bin ein Fan der Vorträge von Jeff Patton, zum einen wegen der inhaltlichen Tiefe, zum anderen wegen seines besonderen Stils, Life Visualisierungen für seine Ausführungen zu erstellen. In diesem Fall zum Thema des Minimum Viable Product (MVP).

Spannend an diesem Vortrag ist unter anderem, dass er durch die Erläuterung des MVP scheinbare Gewissheiten der agilen Produktentwicklung in Frage stellt, zum Beispiel die Definition of Done - aber nicht etwa, weil er in dieser Idee keinen Sinn sieht, sondern weil er aufzeigen kann, dass sie nur Teile dessen abdeckt, was man unter agil verstehen kann. 

Auf den ersten Blick ist das hier einer dieser Holy Shit-Momente. In gerade einmal fünf Minuten erstellt Henrik Kniberg hier mit Hilfe eines KI-Chatbots einen funktionsfähigen Prototypen einer mobile App in mehreren Versionen, samt Dokumentation und einem initialen Backlog mit den nötigen Anforderungen um daraus eine voll funktionsfähige erste Version zu erstellen. Früher wäre damit ein ganzes Team einen ganzen (Design-)Sprint lang beschäftigt gewesen, jetzt geht es in wenigen Momenten.

Wenn man weiss wie derartige Chatbots funktionieren relativiert sich die Leistung ein bisschen. Das Demonstrationsobjekt ist eine To Do-Listen-App, von denen es bereits unzählige gibt, deren Code hier Teil des Traningsmaterials der KI gewesen ist. Würde man sie dort einsetzen wo Prototypen normalerweise gebraucht werden, in der innovativen Neuentwicklung nämlich, wäre kaum Trainingsmaterial vorhanden und das Resultat wäre entsprechend wenig beeindruckend.

Trotzdem bleibt das Ergebnis dieser Vorführung natürlich beachtlich. Um das Potential dieser Technologie voll nutzen zu können, wird es darauf ankommen, zu wissen, wo sie einsetzbar ist und wo nicht. So werden sich beispielsweise die wenig innovativen Teile einer neuen Anwendung (Login, Profilseite, etc.) schnell generieren lassen, so dass mehr Zeit für die wirklich innovationsbringenden Tätigkeiten bleibt. Alleine das kann schon sehr viel bewirken.

Am Ende sollte trotzdem in jedem Fall klar sein, dass der auf diese Art entstandene Code mindestens durch ein gründliches Refactoring gehen, wenn nicht sogar neugeschrieben werden sollte, bevor er veröffentlicht wird. Wenn nicht, dürften einige unschöne Überraschungen bevorstehen. Selbst das kann im Vergleich zu einer vollständigen Selbstentwicklung aber immer noch deutlich effektiver und effizienter sein. Die Zukunft hat bereits begonnen.

Man soll ja Erfolge nicht nur feiern, sondern auch in Erinnerung behalten, denn wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann sonst leicht in Frustration abrutschen. Um es nicht dazu kommen zu lassen, möchte ich von einer weiteren "agilen Erfolgsgeschichte" erzählen, die sich einmal im IT-Systemhaus einer grossen Bankengruppe zugetragen hat, bei der Entwicklung eines neuen Onlinebanking-Systems.

Agiles Arbeiten steckte dort noch in den Anfängen, und wie in vielen anderen Unternehmen auch wurde noch davon ausgegangen, dass es sich dabei nur um eine neue Arbeitsweise für die Software-Entwicklung handeln würde. Andere Organisationseinheiten reagierten nur mit einer Mischung aus Amüsiertheit und Entrüstung, als angeregt wurde, dass auch sie ihren Arbeitsmodus ändern sollten. Ihre Ideen waren klar: sie wollten im Voraus definieren, was sie wollten, und dann warten bis es fertig war.

Was zu ihrer Überraschung anders war, war aber, dass ihnen schon früh mitgeteilt werden konnte, wie (un)realistisch ihre Vorstellungen waren. Durch feature- statt komponentenorientierte Entwicklung, frühe Integration und automatisiertes Testen war der reale Arbeitsfortschritt klar erkennbar, und durch eine grobe Schätzung der noch offenen Anforderungen auch die noch nötige Zeit, beziehungsweise die vermutlichen Liefertermine der fehlenden Features. Und nätürlich - die waren später als gewünscht.

Die ersten Reaktionen darauf waren abwiegeln und abstreiten. Es wäre doch noch viel zu früh für solche Aussagen, die Roadmap wäre schliesslich von Experten gemacht worden, die Entwicklungs-Teams müssten nur bereit sein, "etwas Gas zu geben", dann würde der Zeitplan wieder passen. Und so weiter. Allein - alle drei Wochen bestanden die Entwickler in den Sprint Reviews auf ihren schlechten Botschaften. Im ersten Quartal, im zweiten, im dritten, und am Anfang des vierten.

Wenige Monate blieben damit noch bis zum geplanten Go Live in der ersten Tochtergesellschaft, und plötzlich wollten auch die anderen Organisationseinheiten agil werden. Besonders ein Begriff hatte es ihnen auf einmal angetan: das Minimum Viable Product (MVP), in ihrem Verständnis ein nur auf das absolut Notwendige reduzierter Funktionsumfang, mit dem der anvisierte Termin noch irgendwie zu halten sein müsste. Den wollten sie haben, und den glaubten die Entwickler auch liefern zu können.

In der Folgezeit wurden die Anforderungen Seite um Seite zusammengestrichen. Opulente Redaktions-Workflows? Erstmal nicht. Der komplette Nachbau aller Features des alten Systems im Neuen? Völlig übertrieben. Die Umstellung aller internen CMS-Seiten auf die Fonts, Formen und Farben des Corporate Design? Unnötig. Etc. Am Ende blieb nur ein letztes der unrealistisch grossen Arbeitspakete übrig, das angeblich nicht verhandelbar war. Das so genannte Reporting Center.

Dieses letzte laut Compliance-Abteilung zwingend nötige Feature sollte sicherstellen, dass sich nachvollziehen liess, welcher interne Mitarbeiter wann welche Änderungen in dem Onlinebanking-System vorgenommen hatte. Zu diesem Zweck sollte es möglich sein, sich alle Änderungen anzeigen zu lassen, sie nach Zeitraum, Bearbeiterrolle oder betroffenem Teilsystem zu filtern und grafisch aufbereitet anzeigen zu lassen. "Wenn es das nicht gibt, macht uns die Bafin den Laden zu", hiess es.

Als zwei Wochen vor Weihnachten absehbar wurde, dass auch diese Drohung nicht zu einer wundersamen schnellen Fertigstellung führen würde, fiel auf einmal auch hier das neue magische Wort. "Gibt es nicht auch davon ein MVP, und wenn ja, welches?" Und es gab eines - eine aus dem System exportierte Tabelle aller Bearbeitungsvorgänge, mit dem Angebot der Entwickler, ggf. beim Verständnis zu helfen. Und ein inoffizielles Vorfühlen bei der Bafin ergab: für die erste Version würde das reichen.

Und damit war es geschafft. Das Go Live in der ersten Tochtergesellschaft konnte wie geplant stattfinden, und nicht nur das. Die dort mit dem MVP-System arbeitenden Mitarbeiter konnten gefragt werden, wie sie mit dem System zurechtkamen, ihnen konnte gesagt werden, welche Features sonst noch geplant waren, und was sie vermutlich kosten würden. Und völlig überraschend kam das Feedback, dass viele davon gar nicht benötigt würden und stattdessen etwas Anderes sinnvoll wäre.

Dem Vernehmen nach ist das etwas überdimensionierte Reporting Center irgendwann doch gekommen, aber trotzdem enthält diese Geschichte einigen von dem, was agiles Arbeiten so wirkungsvoll macht: frühe Auslieferung, hohe Transparenz, ständiges Feedback, ein MVP, aus dem man mehr über die echten Bedürfnisse echter Anwender lernen kann und eine Anpassung der Pläne an die Realität (statt des Versuchs das Gegenteil zu erzwingen). Und all das in einer stark regulierten Branche.

Es gibt einige ältere Dinge die so cool sind, dass sofort zwei Reaktionen hochkommen wenn man sie sieht: 1) "Wow, das gibt es schon so lange?" Und 2) "Oh Mann, warum wurde davon nicht viel mehr gemacht?"
Die Seite Something Agile Lean Something gehört auf jeden Fall in diese Kategorie, denn auf Ihr wurden schon 2015 eine Reihe von Begriffen aus dem agilen Kosmos mit gezeichneten Star Wars-Lego-Figuren erklärt. Leider sind insgesamt nur acht Panels zusammengekommen, die sind aber alle wirklich sehenswert. Hier ist mein Favorit, die Erklärung verschiedener Typen von MVPs:

Zum Vergrössern auf die Grafik klicken

Dieses und die anderen Panels können auf der Seite somethingagileleansomething.com in hoher Auflösung heruntergeladen werden, alle unter der Creative Commons-Lizenz CC BY-NC-ND 2.0.

Fehlt noch etwas um den Popkultur- und Methoden-Nerd vollkommen zu begeistern? Natürlich, ein Easter Egg. Bitte noch einmal alle Augen auf die oben zu sehenden "MVP-Flavors". In ihnen gibt es eine Referenz auf eines der bekanntesten MVPs der Technik-Geschichte. Noch nicht gefunden? Die Auflösung gibt es hier.

Grafik: Wikimedia Commons / Teemu Leinonen - CC BY-SA 4.0

Es ist einer der grossen Klassiker: verschiedene Menschen unterhalten sich über einen Begriff, jeder geht davon aus, dass alle das Selbe darunter verstehen aber in Wirklichkeit hat jeder sein eigenes Verständnis, so dass alle aneinander vorbeireden. Das habe ich schon an verschiedenen Beispielen aufgezeigt, und heute kommt ein weiteres dazu: das Minimum Viable Product (MVP). Auch hinter dem können sich sehr unterschiedliche Ansätze verbergen, und zwar die Folgenden:

I. Der Proof of Concept (PoC)

Rein formal kein MVP im eigentlichen Sinn, da hier noch kein benutzbares (→ viable) Ergebnis entsteht. Der in den 60er Jahren bei der NASA geprägte Begriff lässt sich als "Machbarkeitstest" ins Deutsche übersetzen. Ein erfolgreicher PoC beweist "nur", dass ein Vorhaben technisch machbar ist, validiert aber nicht ob es für das geplante Produkt auch einen Bedarf gibt. Ein Proof of Concept kann rudimentärster Art sein, z.B. indem er beweist, dass ein Material einer bestimmten Belastung standhält oder dass eine Datenauswertung gegen kein Persönlichkeitsrecht verstösst.

II. Der Riskiest Assumption Test (RAT)

Der erste Ansatz der auf Eric Ries zurückgeht, der Ende der 2000er Jahren mit seinem Lean Startup-Framework den Begriff des MVP bekannt gemacht hat. Er geht davon aus, dass vor dem ersten eigentlichen MVP grundlegende Annahmen geklärt werden können, z.B. die ob sich überhaupt jemand für die (Produkt)Idee interessiert. Das kann z.B. durch Fokusgruppen-Marktforschung geschehen oder durch Experten-Interviews. Ries bezeichnete diese Grundannahmen als "Leap-of-Faith-Assumptions", durch Rik Higham wurden sie später als "Riskiest Assumptions" popularisiert, die durch Riskiest Assumption Tests validiert werden können.

III. Das Low Fidelity MVP (Low-Fi MVP)

Das erste MVP im eigentlichen Sinn. Eric Ries versteht darunter eine extrem rudimentäre Version eines Produkts, deren einziger Zweck das Validieren von Kunden- oder Nutzer-Interesse ist. Legendär ist das Low-Fi MVP des online-Schuhhändler Zappos, das nur aus einer Website mit Schuh-Fotos und einer Bestelladresse bestand. Auf der Website Robot Mascot gibt es eine schöne Übersicht über weitere Varianten, die dort auch erklärt werden: Customer Interview, Social Media-Auftritt, Aktivität in Online-Foren, Landing Page, Split-Testing, Erklärvideo, Papier-Prototyp, Ad Campaign, "Fake Door", Audience Building und Micro-Survey.

IV. Das High Fidelity MVP (High-Fi MVP)

Ebenfalls eingeführt durch Eric Ries sind die High Fi-MVPs zwar noch immer rudimentär, in der Erstellung aber bereits deutlich anspruchsvoller. Z.B. für Prototypen in der Hardware-Fertigung gedacht wird das Produkt hier digital simuliert oder mit relativ hohem Fertigungsaufwand in geringer Stückzahl erstellt, etwa für öffentliche Vorführungen auf Messen. Aufwändige MVPs für komplexe rein digitale Produkte existieren aber ebenfalls. Auch hier gibt Robot Mascot eine Übersicht und Erklärung für verschiedene Varianten: Digitale Prototypen, 3D-Modelle, “Wizard of Oz” MVPs, “Concierge”-MVPs, The “Piecemeal”-MVPs, Crowdfunding und Single Featured MVPs.

V. Das Minimum Marketable Product (MMP), bzw. Earliest Loveable Product (ELP)

Eine wesentlich fortgeschrittenere (und ironischerweise auch wesentlich ältere) Variante des MVP. Eingeführt 2001 durch Frank Robinson, den Erfinder des Begriffs Minimum Viable Product, beschreibt sie einen Produktumfang der zwar noch klein ist, trotzdem aber bereits gut genug entwickelt ist um an den Markt gebracht werden zu können. Beispiele dafür wären die ersten, noch sehr minimalistischen Versionen von Facebook (ein Studenten-Verzeichnis) und Twitter (eine Chatgruppe). Robinson benutzte seinerzeit noch den MVP-Begriff in diesem Sinn, nachdem der durch Eric Ries umgedeutet wurde gab es Versuche von Neubenennungen 2011 durch Roman Pichler (MMP) und 2015 durch Henrik Kniberg (ELP).

VI. Der Meilenstein-MVP

Gehört am wenigsten in diese Aufzählung, tritt in der Realität aber immer wieder als Missverständnis auf. Wie der Name schon sagt - es ist nicht anderes als der alte Meilenstein, also eine mehr oder weniger sinnvoll geschnittene Kombination aus Arbeitspaket und Deadline, die jetzt nur einen neuen Namen trägt. Ein starker Indikator für Cargo Cult.

Bild: Wikimedia Commons/Visitor7 - CC BY-SA 2.0

• Der erste Typ ist das Earliest testable Product
  Beispielsweise könnte das die allererste Form eines CMS sein, die zunächst nur mit unformatiertem Text befüllbare Seiten anlegt. Testbar, aber noch weit davon entfernt den Ansprüchen der Benutzer gerecht zu werden.
• Der zweite Typ ist das Earliest usable Product
  Um beim Beispiel zu bleiben: Der Text der erstellten Seiten ist formatierbar, es lassen sich Bilder und Videos einbetten, die Redakteure können damit bereits arbeiten, selbst wenn noch einiges fehlt.
• Typ drei ist das Earliest loveable Product
  Freigabe-Workflows, Verschlagwortung, Social Media-Einbindung und Autorenprofile - jetzt ist eigentlich alles da um an den Markt zu gehen. Es geht zwar noch mehr, aber vermarkten lässt sich das Ganze bereits.

Der Vorteil an diesem Vorgehen: man kann mit den verschiedenen Untertypen die verschiedenen Teil-Zielgruppen da abholen wo es Sinn macht - etwa die IT-Abteilung des Kunden mit dem Earliest testable Product, die Redakteure mit dem Earliest usable Product und das Marketing mit dem Earliest loveable Product. Jeder bekommt in etwa das was er will, keiner bekommt etwas vorgesetzt was ihn völlig über- oder unterfordert, Konfliktpotential entsteht gar nicht erst. Und in der Praxis ist so etwas bereits jetzt in gewisser Weise üblich, was sich zum Beispiel darin ausdrückt, dass die Geschäftsführung nur zu den Reviews im Vorfeld größerer Releases kommt. Während sich das aber eher selbst reguliert bieten Knibergs Untertypen die Gelegenheit Erwartungsmanagement zu betreiben und die verschiedenen Stakeholder dorthin zu bekommen wo es Sinn macht und wo sie auch selber sein möchten.

Nachtrag 26.01.2016:

Kniberg hat seine Gedanken nochmal ausführlich selbst aufgeschrieben.