Werfen Sie Ihre Vorurteile über Bord und erfahren Sie, warum erfolgreiche Unternehmen das MVP als Schlüssel zur Zufriedenheit ihrer Kunden betrachten.
Von Arbi Vartan und Jeff Brinkerhoff
Slalom liebt Agile. Wir sind begeistert von den realen, messbaren Vorteilen, die wir bei Unternehmen beobachten konnten, und wir sprechen über einige der größten Vorteile in einer Reihe von Blogbeiträgen und einem kostenlosen Agile-Webinar – sehen Sie es sich auf Abruf an.
Das MVP, oder Minimum Viable Product, ist ein grundlegendes Element in der Praxis von Agile. Und es ist auch etwas, das Widerstand hervorruft. Wir haben unsere Kunden Dinge sagen hören wie: „Unsere Führungskräfte wollen nicht das Minimum – sie wollen die bestmögliche Qualität.“ Warum sollte man denn nicht sein Bestes geben wollen? Das ist eine gute Frage, die jedoch auf einem Missverständnis des MVP beruht.
Das MVP wurde 2001 von Frank Robinson entwickelt und von Eric Ries mit seinem Buch Lean Startup populär gemacht und ist zu einem Grundpfeiler leistungsstarker Produktteams auf der ganzen Welt geworden. Warum ist Google seit so langer Zeit so dominant? Warum stellt Apple einige der beliebtesten Produkte der Welt her? Warum hat Netflix nicht nur überlebt, sondern gedeiht über sein ursprüngliches Geschäftsmodell hinaus? Viele Faktoren haben dazu beigetragen, aber ein gemeinsamer Nenner ist, dass sie alle den MVP verwenden.
Was also ist der MVP? Hier ist die Definition von Eric Ries: Diejenige Version eines neuen Produkts, die es einem Team ermöglicht, mit dem geringsten Aufwand ein Maximum an validiertem Wissen über die Kunden zu sammeln.
Wie diese Definition deutlich macht, ist der MVP kein Produkt mit der geringstmöglichen Funktionalität, die für eine öffentliche Markteinführung erforderlich ist. Es hat nichts damit zu tun, ein Produkt überhaupt öffentlich freizugeben. Vielmehr ist der MVP der Schlüssel zur Anwendung der wissenschaftlichen Methode bei der Produktentwicklung. Es ist ein reiner Mechanismus für validiertes Lernen, der dazu dient, Hypothesen zu testen und herauszufinden, was die Bedürfnisse der Kunden erfüllt.
Schmeißen Sie den Begriff weg, wenn Sie müssen, aber behalten Sie das Konzept
Bei Slalom haben wir das Konzept des MVP sowohl in die Art und Weise integriert, wie wir Produkte für Unternehmen entwickeln, als auch in die Art und Weise, wie wir mit ihnen zusammenarbeiten, um die Vorteile der Einbeziehung agiler Prinzipien und Praktiken in ihr Geschäftsmodell zu nutzen. Nach mehr als zwanzig agilen Unternehmenstransformationen und Hunderten von Partnerschaften in verschiedenen Branchen haben wir jedoch festgestellt, dass es manchmal einfacher ist, die Verwendung von Begriffen wie MVP nicht zu erzwingen. Einige sind zu dem Begriff „Minimum Lovable Product“ übergegangen, und Henrik Kniberg (am besten bekannt für seine Arbeit mit der Spotify-Entwicklungskultur) schlägt die Verwendung der Begriffe Earliest Testable, Earliest Usable und Earliest Lovable Products vor.
Jeder dieser Begriffe ist in Ordnung. Bei Agile geht es um glücklichere, produktivere Teams – nicht um Terminologie. Unsere Herangehensweise an dieses oder jedes andere falsch interpretierte, unklare agile Konzept besteht darin, das Wort zu übergehen und die folgenden drei Fragen zu stellen:
- Warum? Im Fall des MVP geht es um schnelles Lernen und um die zugrunde liegenden Prinzipien: Kundenzufriedenheit, kontinuierliche Verbesserung und Einfachheit.
- Was wäre nötig, um es in meinem Unternehmen umzusetzen? Oh, die Macht des Rahmens! Anstatt zu fragen, ob Sie es schaffen können, konzentrieren wir uns auf die Hindernisse – organisatorische oder andere. Die Antwort auf diese Frage kommt oft in Form von Zustimmung von Personen, die als unbeweglich galten.
- Was wäre, wenn wir es nicht tun würden? Eine weitere Strategie: Konzentrieren Sie sich auf die Kosten der Beibehaltung des Status quo. Dies kann ein Gefühl der Dringlichkeit vermitteln und eine neue Arbeitsweise fördern.
Hier eine Geschichte über die Gefahren des Status quo: Bei einem Projekt in einem Unternehmen, mit dem wir kürzlich zusammengearbeitet haben, wurde sechs Monate lang an einer größeren Softwareversion gearbeitet, die mehr als 200 interne Benutzer betraf. Sie schlossen sich in einem Raum ein und schlossen die Entwicklung und alle Tests ab. Und erst zu diesem Zeitpunkt wurde das Feedback einer Handvoll stellvertretender Geschäftsanalysten eingeholt – und nicht von den tatsächlichen Benutzern. Diese Art von Checkbox-Aktivitäten, die zu spät kommen, um noch etwas bewirken zu können, und bei denen der Schwerpunkt nicht wirklich auf validiertem Lernen liegt, kann kaum als Einholung von Feedback bezeichnet werden. In Wirklichkeit ist es ein Versuch, das Unvermeidliche zu bestätigen.
Das Ergebnis war vorhersehbar. Da bereits so viel Zeit und Geld investiert worden war, sah man sich gezwungen, weiterzumachen, und alle 200 Benutzer lehnten die neue Software wegen ihrer langsamen Leistung und mangelnden Benutzerfreundlichkeit ab. Sechs Monate und mehr als 12 Millionen Dollar wurden ausgegeben, und als Ergebnis gab es nur Schuldzuweisungen zwischen den Geschäfts- und Technikteams.
Stellen Sie sich nun dasselbe Szenario mit einem MVP vor, das einer Gruppe von Endbenutzern zu Beginn des Projekts zur Verfügung gestellt wurde. Die Entwickler könnten sofort lernen, was sie falsch gemacht haben, und dann weitere MVPs einsetzen, die iterativ verbessert werden, bis ein endgültiges Produkt bereitgestellt wird, das mit echten Benutzern entwickelt und von ihnen genehmigt wurde. Ein weiterer Vorteil: Die Benutzer in der Testgruppe würden sich sehr für das Projekt engagieren und es unter ihren Kollegen verbreiten.
Wir haben genau dieses Szenario erlebt, und deshalb glauben wir fest an das MVP – wie auch immer Sie es nennen wollen.