Einer der coolsten Tatsachen über unsere Arbeit als hands-on Berater ist die, dass wir ständig mit mehr oder weniger neuen Problemen konfrontiert werden.
Dazu passt, dass bei einem unserer Kunden der Produktentwicklungsprozess nach Scrum an seine Grenzen gestoßen war. Seine Softwareentwickler und Designer waren zwar in einzelnen Scrum-Teams organisiert, aber das fühlte sich für alle Beteiligten eher wie eine Zwangsmaßnahme an, da sie meist an völlig unterschiedlichen Problemen gearbeitet haben. Vom Markt geforderte Features hatten oft eine – im Vergleich zur Konkurrenz – hohe Durchlaufzeit (eng. "lead time"), bedingt durch zu späte Eskalationen entweder durch die Softwareentwicklung, oder durch die UX-Designer. Innovative Themen wurden kaum mehr angegangen, da im Alltag kaum Zeit übrig blieb.
Ganz konkret war der Product Owner als einziges Bindeglied zwischen den Teams kurz vor dem Burn-out. Immer wieder musste er zwischen den Designern und Entwicklern vermitteln. Die Designer – hoch kreative Menschen – hatten tolle Ideen, die sie den Entwicklern zu unterschiedlichsten Zeitpunkten über den Zaun geworfen haben. Die Entwickler – hoch fokussierte Menschen – haben ständig darauf hingewiesen, dass ihre Vorstellungen nicht umsetzbar sind und die geforderte Spontanität das Sprint-Ziel gefährdet.
Unser Kunde hatte ohne große Anpassungen beide Gruppen einfach in ein Scrum-Team gekippt. Mit den bisherigen Ergebnissen war aber klar, dass eine Neugestaltung des Vorgehens nötig ist, die sowohl die Teams zu mehr Zusammenarbeit motiviert, als auch den Innovationsprozess beschleunigt und seine Qualität steigert.
Die Lösung lag darin, zu verstehen, welche Aufgaben die Teams hauptsächlich zu lösen hatten und darauf zu reagieren und nicht eine "one-size-fits-all"-Lösung zu fahren. Mit den bisherigen Ergebnissen, Rücksprachen mit dem Team und den Stakeholdern wurde klar, dass die Arbeit am Produkt einen starken Innovationscharakter hat.
Ein dazu passender Produktentwicklungsprozess kann, grob gesagt, in zwei Phasen unterteilt werden: Produktdefinition (Discovery) und Lieferung (Delivery). Die Discovery dient dazu, Lösungsmöglichkeiten zu erforschen. Die Delivery, um einsatzbereite Software bereitzustellen. Traditionell beschäftigen sich die UX-Mitarbeiter mit der Definition und die Entwickler sind für die Umsetzung verantwortlich.
Unsere Empfehlung war eine Vorgehensweise, die Discovery und Delivery vereint: Dual Track Agile. Aber eine Sache nach der anderen.
Dual Track Agile ist ein Konzept, der zum ersten Mal von Desiree Sy thematisiert wurde ("Adapting Usability Investigations for Agile User-centered Design", in: Journal of Usability Studies, Vol. 2, Issue 3, May 2007, S.: 112-132; agile-ucd - parallel track dev.pdf). Martin Cagan and Jeff Patton haben das Konzept in ihren Seminaren weiter getragen. Damals noch unter dem Namen Dual Track Scrum (vgl. Dual-Track Agile | Silicon Valley Product Group).
Das Vorgehen vereint verschiedene Ansätze und Methoden: Lean Start Up, Design Thinking, Lean UX und Agile haben. Dieses Konzept sieht vor, dass der gesamte Innovationsprozess von einem Team gesteuert wird, aber auf zwei Strecken (sog. Tracks) verläuft. Diese laufen parallel zueinander.
Die Grafik oben zeigt die parallelen Tracks der Product Discovery und Entwicklung während des gesamten Produktdesign- und Lieferprozesses. Diese regen sich ständig - sehr kontrolliert - gegenseitig an und bilden die Grundlage für neue Hypothesen. Zu sehen und außerdem bis ins Detail super erklärt, ist das auch hier: Dual Track Development is not Duel Track – We help you... oder hier: Wie dich Dual-Track-Development aus der Feature-Factory retten kann.
Sicherlich gibt es einfachere Lösungen, welche die Zusammenarbeit von Teams neu gestalten. Wir würden z. B. mit der Verbesserung der Kommunikation zwischen den Teams und Vereinheitlichung ihrer Ziele anfangen. Das würde aber den Innovationsprozess nicht weiter bringen.
Mit Dual Track Agile lösen wir elegant das Problem. Discovery und Delivery haben unterschiedliche Herangehensweisen bei ihrer Aufgabenbewältigung und trotzdem müssen beide synchronisiert an gemeinsamen Zielen arbeiten. Übergabepunkte, gemeinsame Meetings etc. sind gut aufeinander abgestimmt.
So weit, so gut. Unser Kunde hatte sich jedoch gefragt, welche konkreten Vorteile Dual Track Agile zu bieten hat. Schließlich bedeutete die Umsetzung zusätzlichen Zweitaufwand für die Abstimmung zwischen Discovery und Delivery. Provokant formuliert, könnte man auch wieder auf zwei separate Teams setzen.
Dual Track Agile ist eine Vorgehensweise, User-Experience-Designer in agile Entwicklungsteams einzubinden und die teamübergreifende Zusammenarbeit zu unterstützen, ohne auf die Vorteile - wie das "Fail Fast" - aus der agilen Produktentwicklung zu verzichten. Dazu werden für die Zusammenarbeit, konkreter das Wissensmanagement, die Kommunikation und die Koordination, mit denen Entwicklungsteams zu kämpfen haben, Lösungswege präsentiert.
Im Discovery-Track besteht das Ziel des Teams darin, herauszufinden, was als Nächstes gebaut werden soll. Dies kann Forschungs-, Design- und Testaktivitäten umfassen. Die Teams konzentrieren sich auf die Validierung von Ideen und Lösungen, bevor diese zum Delivery Track geschickt werden.
In der Regel sind die Entwickler nicht die Hauptakteure im Discovery Track. Dennoch können diese in dieser Phase einige wichtige Aufgaben übernehmen:
Neben den o.g. Discovery-Aktivitäten arbeiten die Teams daran, die Produktinkremente im Delivery Track zu erstellen und bereitzustellen. Die Designer kümmern sich z.B.:
Man sieht, die Kooperation wird explizit gemacht und eingefordert. Das Ganze ist sogar sehr gut über ein Product Backlog, mit einem Sprintziel und in Dailies abbildbar. Es kommt echtes Teamgefühl auf und - von uns beobachtet - ergibt sich durch die Klarheit der Aufgaben eine direkte Verbesserung der Zusammenarbeit.
Dual Track Agile hilft, unnötige Entwicklungsarbeit zu vermeiden, da Ideen ständig validiert und nur diese entwickelt werden, die dem Kunden Wert liefern. Man kann sich diesen Track so vorstellen, dass er das Backlog kontinuierlich mit verfeinerten und validierten Storys füllt. Der Fokus liegt auf dem Lernen und der Anpassung auf der Grundlage dieser Erkenntnisse. Wir wollen so schnell, günstig und sicher wie möglich lernen. Geschwindigkeit ist also auch beim Entdecken wichtig – aber das ist Lerngeschwindigkeit (learning velocity). Dies trägt zur Verbesserung der Effizienz und zur Reduzierung von Verschwendung bei.
Ein gut geplanter und ausreichend koordinierter Discovery Track beeinflusst die Qualität - wird das richtige an den Kunden geliefert - positiv, da er folgende Themen sicherstellt:
Wir haben gezeigt, dass sich eine Zusammenarbeit - sofern denn notwendig - zwischen UX und Entwicklung auf dem Papier einfach realisieren lässt. Dual Track Agile hilft enorm, braucht allerdings, wenn es zur Anwendung kommt, auch einiges an Hirnschmalz. Was genau wir damit meinen? Das zeigen wir euch demnächst mit "Dual Track Agile und seine Umsetzung".
Wir stören nicht viel, versprochen ;-)