Der agile Prozess soll nicht erst mit dem Kickoff und dem ersten Sprint beginnen, wir wollen ihn vielmehr so weit nach vorne holen wie möglich: in die Ausformulierung der Geschäftsidee. Dabei spielt es weder eine Rolle, ob der Kunde bereits agil gearbeitet hat, noch ob er ein Startup oder ein bereits etabliertes Unternehmen ist. Gehen wir nicht einfach davon aus, dass die anderen schon wissen, was sie tun – fragen wir nach. Da die Umsetzungsphase nur so gut werden kann wie das gewachsene, gemeinsame Verständnis, das daraus resultierende Backlog und die Zusammenarbeit, beschreiben die folgenden Schritte, wie man vorgehen kann, um Kernaussagen und Koordinaten einer Geschäftsidee zusammenzutragen und User Stories davon abzuleiten.
Agilität fällt nicht vom Himmel
Wir durchlaufen in mehreren Schritten das Geschäftsmodell und versuchen es strukturiert darzustellen. Aus vielen guten Ideen und unterschiedlichen Vorstellungen entsteht die Kontur eines marktfähigen Produktes.
Ein weiterer, sehr wichtiger Aspekt: wir stimmen uns auf die agile Zusammenarbeit ein und lernen gemeinsam methodisch zu arbeiten und Ergebnisse zu produzieren. Rollen wie Product Owner und Scrum Master können aus dem Kontext heraus entstehen und trainiert werden. Das gewachsene Verständnis und das gemeinsam erarbeitete Backlog lösen die scharfe Trennung in Business- und Development-Teams zu einem gemeinsamen Ziel hin auf. Das alles wird uns später helfen, Probleme frühzeitig zu entdecken und schnell zu lösen. Auch lernen die Mitspieler sich kennen, sehen Stärken und Schwächen lange bevor sie unter Zeitdruck geraten.
Backlog – Quintessenz aus Domain und agilem Wissen
Vor dem Projektstart benötigen wir ein Backblog als Grundlage für die Planung von Ressourcen, Zeit und Budget. Beide Seiten haben ein Grundinteresse, mit dem Backlog eine solide Basis zu erstellen, auf der das Projekt umgesetzt werden kann. Denn Spaß macht es nur dann, wenn die Umsetzung in den Sprints des Scrumprozesses ohne Störungen und mit hoher Geschwindigkeit durchlaufen wird, während sie erkennbaren sowie messbaren Business Value erzeugt.
Whattimeisit?
Eine Time Box muss für jeden Schritt bestimmt und eingehalten werden. So viele Schritte wie möglich durchlaufen, ist wichtiger als die Klärung einzelner Punkte. Wir wollen wissen, wo es gut läuft, vor allem aber, wo es hängt. Schließlich wollen wir mit einem vollständigen Produkt auf den Markt gehen und nicht mit einem perfekten Detail.
Business sichtbar machen, modellieren und schärfen
Wir verlassen uns nicht auf bestehende Dokumente wie den Business Plan oder die Beschreibung der Anforderungen, sondern bauen gemeinsam mit dem Kunden ein greifbares Abbild des zukünftigen Produktes. Hier geht es nicht um Standardlösungen, sondern um die Wahl der zum Projekt und den Mitspielern passenden Werkzeuge.
Hausaufgaben
Der Kunde erhält vorab Aufgaben, um eine Basis für die Arbeit sicher zu stellen. Das können z.B. das Schreiben eines Elevator Pitch und das Erstellen eines Business Model Canvas (bzw. in der für Startups abgewandelten Form Lean Canvas) sein. Oder die weitere Vertiefung eines Business Model Canvas in einem Value Proposition Canvas, um Customer Segement und Value Proposition noch detaillierter zu bekommen. Der Kunde sollte sich unbedingt Gedanken zu den Personas machen, am besten bringt er sie ausformuliert mit. Diese Vorbereitung hilft dem Kunden, seine Ideen auf den Punkt zu bringen und dem Workshop, die nötige Fahrt aufzunehmen.
Los geht’s
Je nach Projektumfang durchlaufen wir in einem oder mehreren Workshops verschiedene Aufgaben.
Die Qualität der gemeinsamen Arbeitsgrundlage können wir mit einem Wert erfassen, den ich hier als Project-Readiness-Index einführen möchte. Wir geben jeder Aufgabe eine Punktzahl. Sind wir mit dem Ergebnis nicht zufrieden oder gibt es offenkundigen Dissenz, ziehen wir Punkte ab. Wir sollten auch einen Abbruchwert definieren, bei dem der Workshop beendet wird, da die Grundlage für weitere Schritte fehlt. Dieser Schritt wird zwischen den Teilnehmern ausgehandelt. Ich gehe im Folgenden weiter auf den Index ein.
| Aufgabe | Max. Wert | aktueller Wert |
| Was sind meine Ziele? | ||
| Elevator Pitch formulieren | ||
| Personas | ||
| Business Model Canvas | ||
| Story Mapping |
1. Was sind meine Ziele?
Der Kunde formuliert seine Ziele für den Workshop, gemeinsam wird eine Number One Reason identifiziert und aufgeschrieben. Wir setzen die erste Messlatte für die nachfolgenden Aufgaben: Sie müssen sich in der Number One Reason widerspiegeln, tun sie das nicht, müssen wir die Number One Reason oder die nachfolgenden Ergebnisse hinterfragen und unter Umständen neu definieren. Abweichungen dürfen nicht hingenommen werden. Sie kommen als böse Überraschung in der Umsetzungsphase zurück, und je später sie kommen, desto teurer werden sie.
Hier sollte die volle Punktzahl erreicht werden. Kann eine Number One Reason nicht gefunden werden oder entfernt sich der Workshop inhaltlich zu stark von der Number One Reason, ohne dass sie reformuliert werden kann, muss der Abbruch diskutiert werden.
2. Elevator Pitch formulieren
Der Kunde bringt einen vorformulierten Elevator Pitch mit, der noch mal gemeinsam aufgeschrieben und wo nötig umformuliert wird. Wir achten streng darauf, dass wir eine knappe Formulierung einhalten, die möglichst alle Punkte berücksichtigt.
Der Elevator Pitch sollte in etwa diesem Schema folgen:
- For [target customer]
- who [statement of need or opportunity]
- the [project name]
- is a [product category]
- that [key benefit, compelling reason to buy].
- Unlike [primary competitive alternative]
- our project [statement of primary differentiation].
Beim Elevator Pitch ist volle Punktzahl anzustreben, denn ebenso wie bei der Number One Reason werden Differenzen, Unsicherheiten oder Lücken, die hier nicht ausgeräumt werden können, später den Umsetzungsprozess stören.
3. Business Model Canvas
Auch hier hat der Kunde im besten Fall bereits Vorarbeit geleistet, die er jetzt präsentiert. Gemeinsam werden Unstimmigkeiten oder fehlende Elemente besprochen. Wir schauen bereits mit einem Auge auf das spätere Story Mapping und versuchen mit Nachfragen offene Punkte zu schließen oder Widersprüche aufzulösen. Bitte den Blick auf die Uhr nicht vergessen! Wenn hier Probleme offenkundig werden, die in der Zeit nicht gelöst werden können, kann ein Folgetermin mit einem größeren Zeitfenster vereinbart, die kritischen Stellen können notiert werden. Der Verständnisgewinn im nachfolgenden Story Mapping kann eine gute Voraussetzung zum Gelingen des Business Model Canvas in einer weiteren Runde werden. Im fertigen Business Model Canvas sollen die für das Story Mapping notwendigen Personas, Goals und Activities erkennbar sein.
Kommt der umfassende Blick auf das Business Model Canvas nicht vom Fleck, kann man versuchen, mit einer Verengung des Fokus auf das Value Proposition Canvas einen Ausgangspunkt zu schaffen.
Oder das fertige Business Model Canvas wird im Value Proposition Canvas in den Bereichen Value Proposition und Customer Segment weiter mit Details angereichert und verfeinert.
Der Project-Readiness-Index sollte jetzt über der Abbruchschwelle liegen, Unstimmigkeiten können unter Umständen noch über das Story Mapping ausgeglichen werden. Gab es bei den Schritten zuvor schon Nachholbedarf, kann dennoch abgebrochen werden, wenn deutlich wird, dass in summa eine solide Grundlage fehlt.
5. Personas
Wir sollten zu diesem Zeitpunkt Business relevante Personas haben. Ihre prototypische Beschreibung sollte zu den im Business Model Canvas dargestellen Benutzerverhalten passen. Elevator Pitch, Business Model Canvas und Personas müssen zusammen passen. Zeigen sich offenkundige Widersprüche, müssen diese sofort geklärt werden; kann Stimmigkeit nicht hergestellt werden, sollte der Abbruch in Erwägung gezogen werden.
4. Story Mapping
Wir wollen auf einem Board Personas, ihre Goals, die zum Erreichen der Goals notwendigen Activities und User Stories, die diese Aktivitäten möglich machen, auftragen und in der Zeitachse anordnen. Das Business Model Canvas sollte uns ausreichend Informationen liefern, um zu den Personas Goals zu definieren. Haben wir die Goals bestimmt, beschreiben wir die Aktivitäten, mit denen wir diese Ziele erreichen können. Jetzt schreiben wir die Stories, die notwendig sind, um diese Activities zu ermöglichen. Wir versuchen die Stories zu priorisieren, so dass wir Swim Lanes einziehen können, die Versionen wie MVP, MMP oder MMF festschreiben. Die Stories müssen möglichst so geschnitten sein, dass sie aufbauend sind, aber keine Abhängigkeiten beinhalten. Die Vorarbeiten, die wir geleistet haben, helfen uns bei der Anordnung, Formulierung und Bewertung der genannten Elemente.
Wir können unseren Project-Readiness-Index abschließend zusammenrechnen und auswerten. Wenn wir soweit gekommen sind, haben wir viel Wissen gesammelt, das uns bei der zukünftigen Arbeit unterstützt.
Am Ende des Tags haben wir die Konturen des Geschäftsmodelles aufgezeichnet und das Grundgerüst für unser Backlog erstellt. Ist unser Project-Readiness-Index zu niedrig, haben wir einen frühen Indikator dafür, dass wir noch am Konzept feilen, Stakeholder überzeugen, Konsens erreichen müssen. Wir wissen, dass es hakt, auch wo es hakt. Und wir haben es früh und selbst herausgefunden und nicht viel Geld und Zeit investiert, um es uns vom Markt sagen zu lassen. Einem zweifelnden Kunden haben wir auch gezeigt, dass agil nicht die Abwesenheit eines Planes, sondern die Anwesenheit von Struktur und methodischem Vorgehen, das steuerbare Erreichen von definierten Zielen ist.
Der beschriebene Prozess kann mit hilfreichen Tools wie z.B. Stacey Diagram, On-Off-Switch und Product Box unterstützt werden. Kernhypothesen können formuliert und später ausgewertet werden. Mit diesen Tools wird sich Teil 2 beschäftigen.
Die Zeichnungen sind von Anne Trieba
Schreibe einen Kommentar