Wie behält man die Bedürfnisse und Probleme der Kunden stetig im Auge? Richtig! Indem man sie regelmäßig testet, hinterfragt und versteht!
Nachvollziehbar, aber: eine klassische agile Produktentwicklung sieht das nur indirekt vor, indem sie davon ausgeht, dass der Product Owner die für den Kunden relevanten Features korrekt im Backlog priorisiert hat. Diese Priorisierung der User Stories sollte allerdings fortlaufend und regelmäßig hinterfragt werden – doch auf welcher Basis, wenn die nächste Marktforschung erst in einem Monat abgeschlossen ist, der nächste Kundenworkshop erst in 2 Monaten stattfindet oder der Google Analytics Experte gerade im Urlaub ist? Mit Continuous Discovery kann sichergestellt werden, dass diese Probleme der Vergangenheit angehören.
In diesem Artikel werde ich mein Verständnis und die Vorteile von Continuous Discovery erläutern. Zusätzlich werde ich darauf eingehen, wie man diese Philosophie mit dem notwendigen Commitment, Mind- und Methodenset nachhaltig in der Produktentwicklung verankern kann.
Die Herausforderung
Komplexe Produkte mit begrenzten Ressourcen in kurzen Zyklen zu entwickeln, ist in vielen Unternehmen nach wie vor eine zentrale Herausforderung. Zu diesem Zweck setzen bekanntlicherweise immer mehr Unternehmen auf eine agile Produktentwicklung. Allerdings gibt es nach wie vor Abgrenzungen in der Verantwortlichkeit und in den Zielvereinbarungen der Projektteilnehmer, die über mehrere Abteilungen hinweg im Widerspruch zu den Zielen des eigentlichen Projektes stehen.
Eine Abgrenzung kann beispielsweise die Trennung von Discovery (Research, Analytics, Prototyping, Produktdefinition…) auf der einen und Delivery (Design, Entwicklung,…) auf der anderen Seite sein. Eine Discovery-Phase wird dann – meist zeitlich flexibler – vor die eigentliche Produktentwicklung geschoben und – wenn überhaupt – im Nachgang nur noch sehr selten wiederholt. In diesen Fällen werden die Erkenntnisse aus der Discovery-Phase einmalig zu Beginn und im weiteren Projektverlauf nur noch punktuell in die Entwicklung geschoben.
Auf den ersten Blick sieht der oben beschriebene Ablauf gar nicht verkehrt aus, allerdings kann diese harte Trennung von Discovery und Delivery problematisch werden, wenn beispielsweise…
- …eine gute Projektidee in der Discovery Phase hängen bleibt und ein Dasein in Power-Point-Präsentationen und Marktforschungen fristet
- …das Produktentwicklungsteam nur als „ausführendes Organ“ angesehen wird und Entwicklungen gar nicht mehr hinterfragt, getestet und validiert werden
- …kurzfristig eine Hypothese überprüft werden soll, aber zeitnah keine Ressourcen und kein Know-how verfügbar sind
Schaut man sich den Sachverhalt durch eine UX-Brille an, ist diese Vorgehensweise alles andere als optimal, weil eine fortlaufende iterative Evaluierung komplett entfällt. Das kann wiederum dazu führen, dass über Wochen und Monate hinaus ein Produkt entwickelt wird, welches nur zu Beginn einmalig getestet wurde. Die Gefahr besteht, dass die Nutzerbedürfnisse nach und nach aus den Augen verloren werden und sich das Produkt im schlimmsten Fall in eine völlig falsche Richtung entwickelt.
Was ist Continuous Discovery?
Ein Ansatz, um der oben beschriebenen Problematik aus dem Weg zu gehen, ist es, die Discovery Phase regelmäßig und nachhaltig in die Produktentwicklung einzubinden. Für diesen Zweck stellt Continuous Discovery ein Framework dar, welches die Evaluierung und Fragen nach Kundenwünschen und -bedürfnissen synchron und iterativ in die Produktentwicklung einbezieht. Die beiden synchron laufenden Tracks Discovery und Delivery haben zwar einen unterschiedlichen Fokus, aber das gleiche Ziel: Produkte und Features zu entwickeln, die Nutzer und Kunden lieben werden.
Wie pflege ich meinen Discovery Track?
Neben den “klassischen” User Stories aus dem Delivery Track werden zusätzlich Discovery-Items in das gemeinsame oder in ein separates Backlog priorisiert und im Sprint Planning mit vorgestellt und eingeplant. Die Items können dann einer klassischen Schätzung unterzogen werden oder einen fixen Zeit-Slot im Sprint bekommen. Diese Entscheidung sollten meiner Meinung nach vom PO und/oder Team getroffen werden und ggfs. in einer Retrospektive thematisiert werden.
Prinzipiell ist ein Discovery-Item als reine Hypothese zu betrachten. In vergangenen Projekten habe ich mit folgender einfachen Syntax gute Erfahrungen gesammelt.
Als Team möchten wir herausfinden, ob/wie …
Dazu benötigen wir X Tage/Stunden, die Personen … und nutzen die Methode X
Welche Schritte sind notwendig, um Continuous Discovery nachhaltig in die Produktentwicklung zu integrieren?
Erfahrungen aus vergangenen Projekten haben gezeigt, dass sowohl das Commitment des Unternehmens, das Mindset der Projektteilnehmer als auch der Einsatz der richtigen Methoden und deren Ergebniskommunikation eine wichtige Rolle spielen. Möchte man Continuous Discovery also erfolgreich in die Produktentwicklung integrieren, sollte man sich aller vier Säulen bewusst sein und diese nachhaltig aufbauen und stützen.
Säule 1 – Das Commitment des Unternehmens
Dass ein klares Commitment des Unternehmens und der Stakeholder für eine agile Produktentwicklung kriegsentscheidend sein kann, liegt auf der Hand. Umso wichtiger wird dieses Commitment aber für Continuous Discovery. Denn in diesem Fall muss das Entwicklungsteam noch interdisziplinärer aufgestellt werden und noch mehr Verantwortung, Vertrauen und Handlungsspielraum bekommen.
Säule 2 – Das Mind-Set
Agiles Arbeiten als Philosophie zu begreifen und zu verinnerlichen, ist die eine Sache – als Produktentwicklungsteam noch näher an den Kunden heranzurücken, eine andere. Denn es kann beispielsweise bedeuten, dass man sich
- als Entwickler auch mal in ein Kundeninterview setzt,
- als Designer subjektive Entscheidungen im Rapid Prototyping von heute auf morgen in Frage stellen lässt,
- als Product Owner ein Stück mehr Verantwortung mit dem Team teilt.
Im Rahmen der Continuous Discovery können also durchaus „alte“ Arbeitsweisen in Frage gestellt werden. Und mehr Verantwortung bedeutet in der Regel auch, dass es mehr Diskussionsbedarf geben kann – umso wichtiger, dass die neuen Methoden und Spielregeln gemeinsam beschlossen werden und in der Retrospektive thematisiert werden.
Säule 3 – Die Methoden
Die Methodenauswahl muss keine komplett neue und unbekannte sein. Man kann durchaus auf alt bewerte Methoden zurückgreifen. Wichtig ist hierbei allerdings, dass diese nachhaltig und regelmäßig genutzt werden und im Sprint Planning eingeplant und in der Review mit präsentiert werden. Im folgenden gehe ich auf 5 Methoden ein, die sich meiner Meinung nach sehr gut in einen Continuous Discovery Ansatz integrieren lassen.
Continuous User Testing
In jedem Projekt sollte sichergestellt werden, dass der Product Owner und das Team regelmäßigen Kontakt zu (potenziellen) Kunden und Nutzern bekommen. Hierfür eignen sich automatisierte Remote- oder moderierte Usability-Tests. Letztere benötigen natürlich aufgrund der Rekrutierung etwas mehr Vorlaufzeit. Regelmäßige und früh geplante Terminen schaffen hier Abhilfe. In vergangenen Projekten haben wir alle zwei Wochen jeweils vier Probanden eingeladen. Getestet wurde immer das, was gerade getestet werden konnte oder musste.
Continuous Analytics
Zur fortlaufenden Analyse eignen sich meiner Meinung nach automatisierte Reports (bspw. eine tägliche Auswertung des Conversion-Funnels oder eine Tracking-Auswertung zur Nutzungshäufigkeit der Produktfeatures). Im besten Fall hängt man die aktuellen Kennzahlen und Charts sichtbar an die Wand – das wirkt motivierend und regt zum Nachdenken und Diskutieren an. Pro Sprint sollte es einen oder mehrere Hauptverantwortliche geben, die die aktuellen und laufenden Reports im Blick haben und einen Zeitslot zur Verfügung gestellt bekommen, in dem sie die Ergebnisse analysieren und bewerten können.
A/B Testing
Ebenfalls ein perfektes Mittel, um fortlaufend neue Erkenntnisse zu gewinnen, sind A/B und Multivariate Tests. Am wichtigsten ist es hierbei, dass einmalig die technische Grundlage geschaffen wird, schnell und einfach neue Tests aufsetzen und auswerten zu können. Ist diese Hürde nämlich einmal überwunden, können neue Test-Hypothesen über Discovery-Items schnell und einfach eingeplant werden.
Rapid Prototyping
Ein iteratives und bekanntes Tool: Über ein Discovery-Item eingeplant kann das Rapid Prototyping am ersten Tag mit einem Kunden- oder Teamworkshop starten. Am zweiten Tag entwickeln die festgelegten Projektteilnehmer den ersten Prototypen. In zwei oder drei Folge-Iterationen wird das Ergebnis fortlaufend mit Probanden verprobt und bei Bedarf angepasst. Über diese Methode kann man innerhalb von einer Woche von der Hypothese zu neuen validierten User Stories gelangen.
Design Thinking
Ebenfalls als iterative und durchaus bekannte Methode eignet sich das Design Thinking für den Einsatz in einem Discovery-Item. Es fördert kollaborative Kreativität und geht auch mal gerne unkonventionelle Wege. Ein gut moderierter Design Thinking Workshop kann bereits in 2-3 Tagen neue Erkenntnisse und User Stories hervorbringen.
Säule 4 – Kommunikation der Ergebnisse
Neben der Methodik sind auch die Aufbereitung und Kommunikation der Ergebnisse als kritische Erfolgsfaktoren anzusehen. Hierzu sollte man entweder einen festen Slot im Sprint Review oder ein zusätzliches Discovery Review Meeting einplanen, um die Ergebnisse dem gesamten Team und Stakeholdern präsentieren zu können.
Der Output des Discovery Tracks
Im Gegensatz zu einer klassischen User Story ist der Output eines Discovery-Items in der Regel kein an den Kunden auslieferbares Produkt oder Feature; er ist zunächst ein reines Testergebnis. Aber Vorsicht! Der Output eines Discovery-Items sollte niemals eine reine Dokumentation sein, sondern dazu mindestens einen der drei folgenden Punkte beinhalten:
- Es gibt 1-X neue User Stories für den Delivery Track
- Es gibt 1-X neue Hypothesen für den Discovery Track
- Das Thema wird nicht mehr weiter verfolgt, weil …
Wichtig: Erfahrungsgemäß sollte streng darauf geachtet werden, wie der Discovery Track eingesetzt wird. Zu groß ist die Gefahr, dass man für jede User Story erstmal ein Discovery-Item anlegt, um ein Konzept zu erstellen. Am besten beschränkt man sich auf ein Maximum von X Discovery Items pro Sprint.
Fazit
Nah am Kunden zu entwickeln ist gar nicht so kompliziert. Man muss es nur wollen. Aber aller Anfang ist schwer. Von daher lautet meine Empfehlung, möglichst viele Team-Mitglieder und Stakeholder bei der Reise in die Continuous Discovery mitzunehmen. Denn dann könnt ihr sicher gehen, dass alle vier Säulen stabil stehen.
Wie sehen eure Erfahrungen mit Continuous Discovery und Dual-Track SCRUM aus?
Das von Dir vorgestellte System funktioniert gut, wenn man die nötigen Ressourcen hat, um die Discovery-Items abzuarbeiten. Da muss natürlich auch der Kunde mitspielen. Wenn dieser ein möglichst gutes Produkt haben will lässt er sich oft auch von der Notwendigkeit überzeugen diese Ressourcen frei zu geben.
Aus meiner Praxis fällt es jedoch sehr schwer die Discovery-Items oder bei uns „R&D-Tickets“ vom Team schätzen zu lassen. Da es um die Evaluierung neuer Ideen und Fragen geht. Hier kann man keine Vergleichswerte heranziehen. Wir schätzen diese Tickets daher nicht, sondern setzen uns eine Maximalzeit, in der wir zu einem Ergebnis kommen wollen. Wie macht Ihr das in der Praxis?
Hallo Timo! Danke für dein Feedback. Ich gebe dir in allen Punkten Recht.
Discovery-Items schätzen zu lassen ist nicht trivial. Auch wir haben hierbei in der Vergangenheit häufig mit einer Maximalzeit gearbeitet. Die richtigen Kompetenzen im Team zu haben ist allerdings das A und O, wenn es um das Schätzen geht. Denn genauso wie ein Frontend-Entwickler besser dazu in der Lage ist, die Komplexität einer Image-Slide-Show zu schätzen, so wird ein UX-Designer weniger Schwierigkeiten haben ein „Rapid Prototyping“ für ein Thema XY schätzen können.
Zu deinem Hinweis: „Da muss natürlich auch der Kunde mitspielen.“ Korrekt :) Da wären wir bei Säule 1 „Commitment des Unternehmens“.