Suche
Wie man Lean Startup und Scrum vereint

Produktlabor in der realen Welt

Philipp Knobelspies, Volker Braun

© Shutterstock / TCmakephoto

Mit Lean Startup entwickeln Gründer ihr Geschäftsmodell hypothesengetrieben. Um die Hypothesen zu belegen oder zu widerlegen, entwerfen sie schnell Prototypen und legen sie der Zielgruppe zur Evaluierung vor. Scrum überträgt die flexible und schnelle Entwicklung der Geschäftsstrategie in die Produktentwicklung. Wenn es um schnelles Feedback in kurzen Abständen geht, das sofort berücksichtigt wird, treffen sich die beiden Ansätze. Damit eignet sich die Kombination beider Ansätze besonders gut, um innovative Ideen schnell an den Markt zu bringen und zu testen. Unser Artikel zeigt, wie Sie beide Methoden verknüpfen.

Beim Entwickeln von Hypothesen formulieren Gründer Annahmen und unterscheiden nach Bekanntem und Neuen, so genannte Analoge und Antiloge. Um das Geschäftsmodell anzupassen, wird das Feedback der Testkunden umgesetzt. Anhand des realen Feedbacks verstehen Gründer schnell, ob die Grundannahmen eines Geschäftsmodells tragen und was sich verbessern lässt. In mehreren Iterationen entsteht ein Produkt, das die Bedürfnisse von echten Kunden direkt adressiert. Produktverantwortliche in größeren Unternehmen nutzen den gleichen Ansatz, um neue Produktideen schnell zu validieren. Scrum überträgt die flexible und schnelle Entwicklung der Geschäftsstrategie schließlich in die Produktentwicklung (Abb. 1) (siehe: Pichler, Roman: „Agile Product Management with Scrum: Creating Products That Customers Love“, 2010 & Cohn, Mike: „Succeeding with Agile: Software Development Using Scrum“, 2009).

Abb. 1: Lean Startup und Scrum

Abb. 1: Lean Startup und Scrum

Product Development mit Lean Startup

Im ersten Schritt werden Hypothesen für das Geschäftsmodell erstellt (siehe: Ries, Eric: „The Lean Startup: How Constant Innovation Creates Radically Successful Businesses“, 2011). Das Projektteam führt ergebnisoffene Umfragen oder Interviews mit der Zielgruppe durch. Aus den Interviews leitet der Produktmanager, Innovationsbeauftragte oder Geschäftsführer den so genannten „Problem Solution Fit“ ab. Er hilft, die Probleme und Ziele der Fokusgruppe bei ihrer täglichen Arbeit zu erkennen und eine Lösung für ein Anliegen oder einen Weg zur Zielerreichung abzuleiten. Konkret könnte das so aussehen: Ein Werbemittelhersteller produziert Werbemittel für Geschäftskunden in hoher Stückzahl, zum Beispiel 10 000 Kugelschreiber mit individuellem Design und Kundenlogo. Die Freigabe für Design und Logoplatzierung dauert lange. Der Hersteller produziert ein Produktmuster, schickt es dem Kunden und fertigt nach seinem Feedback weitere Muster an, bis der Kunde eine Freigabe erteilt.

Ein Projektteam aus einem Product Owner und einem Entwickler stellt die Hypothese auf, dass der Freigabeprozess um mehr als die Hälfte verkürzt werden kann und günstiger wird, wenn Designvorschau und Freigabe nur noch digital erfolgen, statt über haptische Produktmuster. Als Product Owner kommen zum Beispiel der Produktmanager, Innovationsbeauftragte oder Geschäftsführer in Frage. Sie nehmen sich vor, diesen Prozess effizienter zu gestalten. Der Product Owner vereinbart Termine mit Kunden, die mit der langen Wartezeit unzufrieden sind. In den Interviews lässt das Projektteam den Kunden frei sprechen und hört genau zu, warum der Freigabeprozess so lange dauert, was in der Zeit beim Kunden passiert, welche Auswirkungen die lange Freigabe hat und wie eine optimale Lösung für ihn aussehen würde.

Zusätzlich nehmen Product Owner und Entwickler die Perspektive des Kunden ein und lassen für sich selbst Werbemittel herstellen. So erleben sie direkt, was dem Kunden beim Einkaufen widerfährt – das so genannte Mystery-Shopping. Nach Interviews und Mystery-Shopping analysiert das Projektteam die Probleme und möglichen Erleichterungen für den Kunden und skizziert eine Lösungsidee als Kern des Geschäftsmodells. Sie wird in überprüfbare Hypothesen zerlegt und konkret festgehalten: Der Kunde bekommt eine E-Mail mit einem Link zum Freigabeprozess. 90 Prozent der Empfänger klicken auf den Link. Die durchschnittliche Freigabezeit dauert weniger als zehn Minuten.

Hypothesen aus Lean Startup nach Scrum übersetzen

Der Kernprozess bei der Verbindung des Lean-Startup-Modells mit Scrum ist die Übersetzung der Hypothesen in den Scrum-Prozess. Bei der Übersetzung geht es darum, Hypothesen zu zerlegen, Kosten und Nutzen jeder Hypothese zu bestimmen, sie in entwickelbare Pakete aufzuteilen und für das Scrum Product Backlog zu priorisieren.

Zuerst unterteilt das Projektteam die Hypothesen im Geschäftsmodell in Bekanntes, so genannte Analoge, und Neues, die Antiloge. Der digitalisierte Freigabeprozess wäre im B2C-Markt ein Analog, da ihn große Onlinedruckereien schon anbieten. Im B2B-Markt ist die digitale Freigabe dagegen ein Antilog, da der Kunde die Freigabe über einen Link für eine hohe Stückzahl und in der Regel einen hohen Auftragswert erteilt. Getestet wird das Vertrauen, dass der B2B-Kunde dem Werbemittelhersteller bei der digitalen Freigabe für eine hohe Stückzahl und einen hohen Geldbetrag entgegenbringt. Das ist das Neue im Geschäftsmodell, ein Antilog, mit dem noch niemand Erfahrung gesammelt hat. Über das Antilog kann man nur in Annahmen sprechen: Hypothesen. Sie eignen sich zum Alleinstellungsmerkmal, zumindest bis der Mitbewerb nachzieht. Es lohnt sich also, Hypothesen so schnell wie möglich zu beweisen und umzusetzen.

Anschließend bewertet das Produktteam jede Hypothese. Dafür ordnet es die Annahmen in eine Matrix mit den Achsen „Wert“ und „Risiko“ ein. Unsere Hypothese, dass die Onlinefreigabe schneller ist als die mit haptischen Produktmustern, landet im Quadranten oben rechts. Sie haben einen hohen Wert und ein hohes Risiko und beschreiben kritische Annahmen für den Erfolg des Geschäftsmodells. Sie sollten möglichst schnell getestet werden, beispielsweise durch einen Prototyp. Zweite Priorität bekommen die „Must-haves“ und „Low hanging fruits“ mit hohem Wert und geringem Risiko. Das können zum Beispiel Analoge sein, die nicht mehr mit dem Kunden validiert werden müssen oder sogar vorausgesetzt werden, etwa die Onlinezahlung. Sie wird einfach mitgeliefert. Zum Schluss prüft man Hypothesen, die wenig Wert bei wenig Risiko versprechen. Hypothesen mit niedrigem Wert und hohem Risiko beschreiben Fälle, die für das Geschäftsmodell nicht relevant sind. Sie werden nicht umgesetzt.

Zuletzt überträgt der Product Owner die Hypothesen in das Scrum Product Backlog. Dafür formuliert er oder sie die Anforderungen aus den Antilogen als User Stories. Sie beschreiben eine zu entwickelnde Produktfunktion und ihren Nutzen in einem Satz und nach einem festen Schema: „Ich als ROLLE will, dass FUNKTION, damit NUTZEN“. Die User Story sagt dem Entwickler, was das fertige Produkt leisten wird und welche Funktionen der Prototyp mitbringen soll. In unserem Beispiel etwa: „Ich als Marketingmitarbeiter will benachrichtigt werden, wenn Designvorschläge zur Auswahl stehen, damit ich mich für ein Design entscheiden und es zur Produktion freigeben kann.“ Die Messpunkte für die Hypothese werden als Akzeptanzkriterium in die User Story aufgenommen. Der Entwickler kann dann zum Beispiel bestimmte Logfunktionen programmieren, um Messdaten für die Hypothese zu generieren – etwa ein Tracking für den Antwortbutton im digitalen Freigabetool.

Nach dem gleichen Muster überführt der Product Owner alle weiteren Hypothesen ins Scrum Backlog, etwa die zum Vertrauen des Kunden in die Onlinefreigabe auch bei großen Aufträgen. Hypothesen werden dabei häufig in kleinere User Stories aufgeteilt, die einzeln messbar sind und in einem Sprint abgeschlossen werden können. Wichtig dabei ist, dass der Bezug zur Hypothese erhalten bleibt.

Aus User Stories Produkte und Prototypen entwickeln

Beim Übertragen der User Stories in das Product Backlog sortiert der Product Owner nach Wichtigkeit, vorgegeben durch die Hypothesenbewertung. Antiloge mit hohem Wert und hohem Risiko werden weit oben im Product Backlog platziert. Analoge sind dagegen beim Nutzer bekannt und müssen nicht mehr im gleichen Umfang wie eine Hypothese validiert werden. Für einen Prototyp sind sie deswegen irrelevant. Beispiel Onlinebezahlfunktion: Sie ist etabliert, der Nutzer erwartet bestimmte Eingabemasken und die Sicherheitsanforderungen sind in Good Practices dokumentiert. Die Produktentwickler setzen voraus, dass die Nutzer diese Funktion annehmen oder sogar erwarten, und dass es bei der Entwicklung keine größeren Stolpersteine geben sollte. Für den Prototypenbau, etwa die Freigabe-E-Mail mit Link zur Landing Page und ein Mock-up des Freigabetools, spielt die Bezahlfunktion also keine Rolle und wird niedrig priorisiert. Trotzdem lohnt es sich, die Anforderung gleich von Anfang an aufzunehmen. So können die Entwickler einen Button im Mock-up einbauen, hinter dem keine Funktionalität steckt.

Für das fertige Produkt werden Analoge sofort als User Stories formuliert, zusammen mit den Hypothesen in der Matrix bewertet und im Backlog einsortiert, mitentwickelt und ausgeliefert. Das Softwareentwicklungsteam übernimmt User Stories für den laufenden Entwicklungszyklus ins Sprint Backlog. Es wird im Sprint nicht verändert. Das Product Backlog mit allen zu entwickelnden Elementen darf dagegen weiter bearbeitet werden.

Pro Sprint setzt das Entwicklungsteam nur die in der User Story beschriebene Aufgabe um. „Goldene Henkel“ werden nicht entwickelt. Am Ende jedes Sprints liefert das Team als „potentially shippable product“ ein Artefakt, mit dem man eine Hypothese angemessen testen kann. Das kann auch ein Prototyp sein, der Stück für Stück zum fertigen Produkt ausgebaut wird. Wichtig ist, dass er schnell mit dem Kunden erprobt und validiert werden kann – etwa statische HTML-Seiten statt einer kompletten Webapplikation. Die Kosten sprechen häufig gegen Wegwerfprototypen. Es ist sinnvoll, von Beginn an auf Qualität zu achten und mit einem qualitativ vernünftigen Ansatz fertige Softwarepakete zu erstellen oder einzelne Elemente, wie zum Beispiel Designs, im Prototyp wiederzuverwenden.

Das Produkt, mit dem Kunden validieren

Nach dem ersten Sprint liefert das Projektteam erste Produktelemente oder Prototypen aus (siehe: Osterwalder, Alexander: „Value Proposition Design: How to Create Products and Services Customers Want (Strategyzer)“, 2014 & Osterwalder, Alexander: „Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers“, 2010). Sie dienen dazu, Hypothesen direkt mit der Zielgruppe zu validieren oder zu widerlegen. In beiden Fällen erhält das Projektteam wertvollen Input für das Geschäftsmodell. Ein Beispiel für die Validierung der Hypothese „Der Kunde kann den Freigabeprozess in weniger als fünf Minuten durchlaufen“ wäre, dass das Projektteam dazu einen Prototyp per E-Mail an die Kunden verschickt. Die Kunden klicken sich durch den Ablauf, über das eingebaute Web-Tracking sammelt das Projektteam die Testergebnisse.

Stimmt die Priorisierung der Anforderungen und Produktelemente, bekommt der Product Owner zuerst die Produkte oder Prototypen, mit denen er Antiloge aus dem Rechts-oben-Quadrant mit hoher Wichtigkeit und hohem Risiko validieren kann. Zur Erinnerung: Diese Hypothesen beschreiben Annahmen über das Geschäftsmodell, die das Produkt vom Wettbewerb abheben. Falls die Hypothesen nicht stimmen, kann der Produktverantwortliche das Produkt- oder Geschäftsmodell überarbeiten und neue Hypothesen entwickeln. Die Sprints geben den Takt für die gesamte Produktentwicklung: Ein Produktverantwortlicher oder ein Business-Development-Team bearbeitet Annahmen zum Markt ebenfalls im Sprint-Modus und taktet beispielsweise Marktstudien entsprechend ein.

Diese Ergebnisse gehen in die Feedbackschleife, die das Lean-Startup-Scrum-Modell so agil macht. Die Zielgruppe prüft die Prototypen, ihr Feedback dient dazu, die Hypothesen zu validieren. Die wichtigste Erfolgsvoraussetzung in dieser Phase ist, die Nutzer nicht zu beeinflussen. Schnell passiert es, dass das Projektteam Daten überinterpretiert und Rückschlüsse zieht, die die eigene Vorstellung unterstützen. Finden in dieser Phase Interviews statt, um das Kundenfeedback einzuholen, besteht die Gefahr, das Gespräch in eine erwünschte Richtung zu steuern oder unbewusst Antworten vorzugeben. Deswegen sollten Ergebnisse nicht überinterpretiert werden, in unserem Beispiel etwa die Tracking-Resultate. Methoden wie das Mehr-Augen-Prinzip helfen dabei.

Für verlässliche Ergebnisse müssen außerdem Test- oder Prototypumgebung valide sein, das bedeutet: Der Test braucht ausreichend Testpersonen aus allen wichtigen Zielgruppen. Als Beispiel: Der Prototyp einer Software schneidet im Test mit Vertretern des Einkaufs, dem Geschäftsführer und zwei leitenden Angestellten des Kunden gut ab. Das Projekt läuft an, doch kurz nach Vertragsunterzeichnung kommt die böse Überraschung: Betrieb und Administration waren an der Entscheidung nicht beteiligt; ihr Feedback zeigt, dass die Software ergänzt werden muss. Das zeigt, dass die Zielgruppe richtig ausgewählt werden und für valide Erkenntnisse ausreichend groß sein muss.

Das häufigste Versäumnis in diesem Prozess ist, dass Produktentwickler oder Product Owner nicht trennscharf definiert haben, was sie herausfinden wollen. Als Folge werten sie falsche Messpunkte aus oder vertrauen falschen Indikatoren: Wie oft die Freigabe-E-Mail geöffnet wurde, sagt in unserem Beispiel wenig aus. Wichtig ist, wie oft der entsprechende Link geklickt wurde.

So rückt das Geschäftsmodell immer näher an den Bedarf der Zielgruppe. Es entstehen neue Hypothesen zur Weiterentwicklung des Produkts. Das Gelernte fließt zurück in das Geschäftsmodell, genauer gesagt in das Wertangebot. Ein Lerneffekt könnte sein, dass Verantwortliche im B2B-Umfeld häufig einen Kostenvorschlag und immer eine Rechnung mit allen steuerrelevanten Angaben benötigen. Die Funktionserweiterungen – Rechnung sofort nach der Freigabe und prominent im Kundenaccount platzierte Rechnungsübersicht – absolvieren auf dem Weg ins Backlog denselben Prozess wie initiale Hypothesen: Priorisieren durch Matrixeinordnung, Messwerte festlegen, als User Stories formulieren, Granularität für Sprints anpassen und aus den Ergebnissen lernen. Dieser Prozess wird wiederholt, bis alle Hypothesen validiert sind, auch die zur Weiterentwicklung des Produkts. Das wird oft vergessen, nach den ersten Meilensteinen schleicht sich ein Gewöhnungseffekt ein. Dabei reicht es nicht, Hypothesen nur initial zu definieren und zu testen. Während der Produktentwicklung und besonders aus dem Feedback der Kunden entstehen Ideen, die zu wichtigen Hypothesen werden können. Es lohnt sich deswegen, das Produkt nach jedem Sprint mit dem Kunden zusammen zu validieren. Dann geht der Ablauf aus Hypothesen aufstellen, bewerten, in User Stories verwandeln, realisieren und Ergebnisse bewerten lassen in die nächste Iteration.

Fazit

Das Konzept Lean Startup wurde 2011 von Eric Ries vorgestellt und hat sich seitdem unter Start-ups und Technologieunternehmen rasend schnell verbreitet. Es sieht iterative Produktreleases vor, spezifiziert sie aber nicht genau. Das leistet Scrum. Kombiniert eignen sich die beiden Ansätze für eine schlagkräftige Produktorganisation: effizient durch kurze Vorlaufzeiten und wenig Abfallprodukte, nah am Kunden durch regelmäßige Feedbackschleifen und kurze Iterationen.

Aufmacherbild: vector people scientists research in laboratory process via Shutterstock / Urheberrecht: TCmakephoto

Verwandte Themen:

Geschrieben von
Philipp Knobelspies
Philipp Knobelspies
Philipp Knobelspies ist Berater und Unternehmer. Nach viereinhalb Jahren als IT-Berater wendet er sein Wissen in der Konzeption und Umsetzung von Projekten und in der Entwicklung von Online- und Marketingstrategien in Start-ups an, unter anderem als Geschäftsführer bei Veralice (veralice.com).
Volker Braun
Volker Braun
Volker Braun arbeitet als IT-Architekt bei MaibornWolff. Seine Schwerpunkte sind Agilität und IT-Architektur. Derzeit baut er in einem Kundenprojekt einen Prototyp für ein großes innovatives Endkundensystem.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: