Was ist Dual Track Agile?
Herausforderungen in der Produktentwicklung
Eine neue Idee keimt bei der „ABCD24 GmbH“. Man könnte doch sicher Wert schaffen, indem man dieses neue „Super-Feature“ XYZ umsetzt. Ein Produktmanager bekommt die Idee zur Umsetzung und macht ein Konzept, stimmt es mit dem Management ab und gibt es dann dem Designer. Der Designer macht das Design, welches dann zur Umsetzung in der Entwicklung landet. Nach fünf Monaten folgt das Release von XYZ und keiner unserer Nutzer verwendet es. (Achtung: Bewusste rhetorische Übertreibung, die Parallelen zu echten Ereignissen sind rein zufällig.)
Ja, das könnte einem bekannt vorkommen und ist auch bei vielen Unternehmen tatsächlich so oder so ähnlich schon passiert. Es wurde in der Vergangenheit schon teilweise sehr viel Zeit in die Lösung von Problemen investiert, ohne dass man wusste, ob dies tatsächlich echte Probleme sind. Zudem hat man Lösungswege gewählt, bei denen nicht validiert wurde, dass sie das Problem auch lösen. Und das Ganze noch in einem Prozess, der sich manchmal eher nach Wasserfall innerhalb der Scrum-Teams anfühlt, also nach einem „Scrummerfall“.
Geht das besser?
Definitiv. Indem man in einer Discovery – so wie wir das bei Chrono24 nun seit diesem Jahr machen – erst einmal Probleme und Lösungen validiert, oder wie Marty Cagan es sagen würde:
“Product Discovery — a rapid series of experiments, primarily using prototypes, that enable us to discover effective solutions to the problems our team is tasked to solve. Solutions that are valuable, useable, feasible and viable”
Eine passende Definition der Discovery kommt von Tim Herbig:
“Product Discovery describes the iterative process of reducing uncertainty around a problem or idea to make sure that the right product gets built for the right audience. Product Discovery offers Product Teams higher confidence in their path forward. It is also the foundation for a successful implementation and launch phase later on.”
Die Discovery dient also dazu, Themen mit einem hohen Grad an Unsicherheit vor der meist aufwendigen Umsetzung zu validieren. Im Idealfall gehen nur Produkte oder Features in die Umsetzung, welche auch tatsächlich Wert für den Kunden und das Unternehmen schaffen (valuable), benutzbar sind und eine gute User Experience bieten (usable) sowie technisch realisierbar sind (feasible). Außerdem soll die Lösung umfangreich genug sein, um das vorliegende Problem zu lösen, aber nicht deutlich größer (viable). Die Lösung echter Nutzerprobleme muss daher immer im Fokus stehen.
“Remember that our higher order objective is to validate our ideas the fastest, cheapest way possible. Actually building and launching a product idea is generally the slowest, most expensive way to validate the idea.” – Marty Cagan
Im sehr umfangreichen Werkzeugkasten der Product Discovery ist es wichtig, das passende Werkzeug für das jeweilige Problem zu wählen, damit wir möglichst schnell zum Ziel kommen.
Für welche Themen ist eine Product Discovery sinnvoll?
Eine Product Discovery ist vor allem dann sinnvoll, wenn:
- es einen hohen Grad an Unsicherheit gibt, es also unklar ist, ob das Problem ein echtes Problem ist,
- es ungewiss ist, ob die angedachte Lösung geeignet ist, das Problem zu lösen oder wie das Problem überhaupt für den Kunden zufriedenstellend gelöst werden kann und
- es Möglichkeiten gibt, überhaupt in die Validierung zu gehen.
“If you can’t measure it, you can’t improve it.” – Peter Drucker
Die Methode Dual Track Agile
Die von uns bevorzugte Methode ist unter dem Begriff Dual Track Agile bekannt. Hierbei gibt es einen ständig fließenden Übergang von Discovery-Phasen in Delivery-Phasen und zurück. Tim Herbig stellt dies in einem Artikel zu Discovery wie folgt dar:
Die Grafik zeigt, dass Product Discovery und Delivery nicht abwechselnd laufen, sondern beide „Tracks“ das Team stetig beschäftigen. Dabei ist es ganz natürlich, dass die Gewichtung mal mehr in Richtung Discovery und mal mehr in Richtung Delivery geht. Das bedeutet auch, dass ein Teil des Teams eher mit der Discovery beschäftigt ist und der andere eher mit der Delivery.
Dennoch ist es absolut in Ordnung und auch gewünscht, wenn sich das Team auch mal als Ganzes mit neuen Themen beschäftigt und in einer der Phasen gemeinsam arbeitet.
Die Product Discovery und die Product Delivery müssen in der Verantwortung desselben Teams liegen, um das Alignment zu erhöhen, Wissenssilos zu vermeiden und die Motivation zu erhöhen. Was könnte motivierender sein, als neben dem „Wie setze ich etwas um“ auch das „Was setzen wir um“ zu gestalten?
Im Gegensatz zum zuvor erwähnten „Scrummerfall“ ist der Arbeitsablauf in Dual Track Agile also nicht dadurch gekennzeichnet, dass jede Rolle Artefakte an den nächsten Schritt weitergibt; vielmehr ist es ein gemeinschaftlicher Prozess. Der Produktmanager, der Designer und die Entwickler arbeiten zusammen, Seite an Seite, um Lösungen für echte Probleme zu finden, zu validieren und umzusetzen!
Fazit
Wir sind überzeugt davon, dass die Product Discovery uns hilft, bessere und passendere Features für unsere Kunden zu bauen. Die Einführung der Discovery ist aber ein großer Change, bei dem die Scrum Teams intensiv begleite werden müssen. Und selbst dann werden einige Fragen und Unsicherheiten bleiben, die erst nach und nach lösbar sind, wie beispielsweise:
- Wie kann ich mich als Entwickler in der Discovery einbringen?
- Wann gehe ich in die Delivery über? Wie intensiv muss ich was testen?
- Wie groß sollen die Probleme für die Product Discovery idealerweise sein?
- Wie vereine ich die Unternehmensziele mit dem Vorgehen der Discovery?
Sobald wir neue Erkenntnisse haben, werden wir hier nochmal einen weiteren Artikel veröffentlichen. 🙂