Mit Dual-Track Agile kann auch UX agil

Agilität bedeutet für den Großteil der Organisationen, in Minimal Viable Products oder Inkrementen zu denken. In der Rolle als User-Experience-Fachleute arbeiten wir hingegen an einer ganzheitlichen User Experience und konzipieren das Big Picture eines Produktes. Einerseits gehören wir als User-Experience-Expertinnen und -Experten zum Team, denn im Team wird eine gemeinsame Produktvision verfolgt. Andererseits fühlen wir uns dem aber nicht zugehörig, da die Konzeption einer Anforderung an die Implementierung derselben Anforderung zeitlich weit voraus liegt. Zu einem bestimmten Zeitpunkt kann es sein, dass wir im Team an unterschiedlichen Bereichen des Produktes arbeiten. Hier treffen zwei Welten aufeinander, die oftmals nur schwierig zu vereinen sind.

Eine Lösung für dieses Problem stellt „Dual-Track Agile“ dar, das aus der Not der User-Experience-Expertin Desirée Sy entstanden ist, ihre UX-Tätigkeiten an die Geschwindigkeiten des restlichen Teams anpassen zu müssen. Sie selbst hatte keinen Namen für dieses Framework festgelegt, jedoch hat sich „Dual-Track Agile“ mit der Zeit etabliert.

Geschichtlicher Hintergrund

2001 wurde das agile Manifest veröffentlicht und viele Unternehmen stellten ihre Produktentwicklung von konventionell auf agil um. Die User-Experience-Fachleute, bei denen es meist um eine ganzheitliche User Experience und das Big Picture ging, wurden vor den Kopf gestoßen, indem nun kleine Inkremente und MVPs entwickelt und konzipiert werden sollten. So ging es auch Desirée Sy. Sy wagte allerdings 2007 eine Veränderung. Sie nahm die Herausforderung an und sprang auf den agilen Zug auf. Ihre Vision war es, User-centred-Design-Praktiken innerhalb eines agilen Frameworks durchzuführen. Die Prozesse von der Entwicklung einer Produktidee bis zu deren Umsetzung sollten in einem Prozess vereint werden. Dazu gehörte auch die Anpassung von Dauer und Granularität der UX-Tätigkeiten. Jeff Patton arbeitete ihre Idee zehn Jahre später weiter aus. Im Folgenden wird der Aufbau von Dual-Track Agile nach Jeff Patton präsentiert.

Aufbau des Frameworks

Das Dual-Track Agile besteht aus zwei separaten Tracks, die in einem gemeinsamen Prozess dargestellt und bearbeitet werden. Beide Tracks werden bei Patton in unterschiedlich langen Zyklen durchlaufen. Dies wird durch die unterschiedlichen Größen der Kreise in der Abbildung ersichtlich. Im oberen Bereich der Abbildung wird der Discovery-Track und im unteren Teil der Development-Track, auch Delivery-Track genannt, visualisiert. Laut Patton sollen diese zwei Aufgabenbereiche in unterschiedlichen Tracks bearbeitet werden, da sie zwei unterschiedliche Arten von Arbeit und auch zwei unterschiedliche Arten von Denkweisen sind. Allerdings sind beide gleichermaßen notwendige Bestandteile der Produktentwicklung und sollten daher auch beide mit den gleichen schlanken und agilen Methoden durchgeführt werden, sodass sie nach Patton innerhalb desselben Prozesses laufen. Was bedeutet das jetzt für die Tätigkeiten in den beiden Tracks?

Discovery-Track

Der Discovery-Track verfolgt das Ziel, potenzielle Lösungen aus Ideen, Problemen und Kunden-/User-Wünschen zu generieren und im selben Zyklus direkt zu validieren. Durch die Validierung wird ein schneller Erkenntnisgewinn verfolgt, der in der Abbildung als „Learning Velocity“ bezeichnet wird. Nach einem Zyklus wird bei jeder potenziellen Lösung darüber entschieden, ob sie im Development-Track weiterverfolgt werden soll oder verworfen wird. Egal, welche Entscheidung über die Lösung getroffen wird, beide Wege führen zu neuen Erkenntnissen im Team. Die Auswahl der als Nächstes zu bearbeitenden Hypothese wird über die Eigenschaften eines hohen Risikos und einer hohen Unsicherheit bestimmt. Wie in der Abbildung unschwer zu erkennen ist, wird die Discovery nicht nur phasenweise zu neuen Releases durchgeführt, sondern findet innerhalb unterschiedlich langer Zyklen durchgehend statt. Es wird bei Patton im Discovery-Track nicht in gleich langen Zyklen gearbeitet, um die Konzeption und Validierung von unterschiedlichen Ideen so kurz wie möglich zu halten und schnell zu der Entscheidung zu kommen – bauen, verwerfen oder weiter lernen. Patton geht hier „lean“ vor und versucht, Ressourcen nicht zu verschwenden. Sobald klar ist, dass eine Idee nicht zu einer potenziellen Lösung für das Produkt führt, soll diese Idee nicht weiterverfolgt werden. Ideen, die jedoch zu Lösungen führen, werden weiter ausgearbeitet und in den Development-Track überführt, wo sie bestenfalls ein bis zwei Sprints später implementiert werden. Wie man sieht, ist auch hier im Dual-Track Agile die Generierung von Produktideen und -lösungen vorgelagert, allerdings handelt es sich hier um wenige Tage oder Wochen und diese Ideen wurden bereits vor der Implementierung validiert.

Development-Track

Im Development-Track geht es um die Umsetzung der Produktideen, die im Discovery-Track generiert und validiert wurden. Output dieses Tracks sind potenziell auslieferungsfähige Produktinkremente. Auf Grund dessen, dass die Idee bereits als adäquate Lösung für das Produkt ausgearbeitet wurde, sind in diesem Track gleich lange und somit planbare Zyklen vorgesehen. Um es deutlich zu machen – der Fokus dieses Tracks liegt auf Planbarkeit und Qualität. Zur Verbesserung dieser zwei Eigenschaften lautet das Motto nach Patton „Release, measure, learn!“.

Dual-Track bedeutet nicht Dual-Team

Auch wenn es zwei separate Tracks sind, wird als ein crossfunktionales Team am gemeinsamen Produktziel gearbeitet. Jedes Teammitglied arbeitet in beiden Tracks mit, auch wenn es durch sein Knowhow und seinen Arbeitsbereich zu einem Track tendiert. Allerdings wird der andere Track tatkräftig mit Knowhow unterstützt. Im Discovery-Track unterstützen die Entwicklerinnen und Entwickler durch ihr Knowhow und analysieren beispielsweise die technische Umsetzbarkeit der Ideen. Im Development-Track unterstützen die User-Experience-Fachleute, um Rückfragen der Entwicklerinnen und Entwickler während des Sprints zum Design oder User Need der Ideen zu klären.

Herausforderungen aus der Praxis

Durch den Einsatz dieses Frameworks in einem Kundenprojekt sind wir während der Einführung auf folgende Herausforderungen gestoßen:

• Teilen der UX-Tätigkeiten auf Zyklusgröße
• Schätzung der UX-Tätigkeiten
• Gefahr zur ungewollten Spaltung des Teams in Discovery- und Development-Team
• Ressourcenverteilung der Teammitglieder auf die Tracks
• Transparenz im Team über beide Tracks

Fazit

Zusammengefasst kann gesagt werden, dass dieses Framework durch die kurzen Zyklen der Ideengenerierung das Potenzial für eine hohe Lernkurve beim Team hat und zu einer schnellen Wertmaximierung bei der Nutzerin oder dem Nutzer führen kann – und zudem durch den gemeinsamen Prozess die Zusammenarbeit des gesamten Teams gefördert wird. Es sollte jedoch bedacht werden, dass auch dieses Framework eine adäquate Einführung benötigt, um die genannten Herausforderungen zu meistern.

Ausgehend von den hier vorgestellten Grundlagen kann ein Artikel über den Einsatz von Dual-Track in Scrum oder Kanban folgen.

Weitere spannende Themen aus der adesso-Welt findet ihr in unseren bisher erschienenen Blog-Beiträgen.