Dual Track Agile und seine Vorteile

Table of Contents

Einleitung

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.

Produktentwicklungsprozess

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.

Zusammenarbeit organisieren

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.

Dual Track Development is not Duel Track - erstellt durch die SVPG

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.

Vorteile

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.

Kooperationsvorteil durch explizite Zusammenarbeit

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:

  • Beratung zur technischen Umsetzbarkeit leisten;
  • Prototypenerstellung durchführen;
  • Entwicklungsdauer und -kosten schätzen, was Einfluss auf die Priorisierung haben kann;
  • Feedback und Vorschläge einholen, insbesondere während Design Thinking Workshops, die von der Vielfalt der Teilnehmer profitieren.

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.:

  • um die Beratung zur Umsetzbarkeit von Designideen;
  • darum, Designentscheidungen zu implementieren;
  • um das Prototyping und das UI-Design;
  • Qualitätskontrolle und Tests durchzuführen;
  • um Lösungen für auftretende Designprobleme.

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.

Geschwindigkeitsvorteil durch mehr Effizienz

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.

Risikominimierung durch Kundenorientierung

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:

  • Entwicklung der Zusammenarbeit von Discovery und Delivery
  • Es wird ein abgestimmter Kundenfokus für beide Gruppen hergestellt
  • Es wird dennoch eine eigene - auf die Aufgaben abgestimmte - Herangehensweise ermöglicht
  • Kundenerwartungen werden erfüllt
  • Es wird das geliefert, was auch versprochen wurde
  • Es wird allen beteiligten Experten ermöglicht, eine umsetzbare Idee zu entwickeln
  • Ressourcen werden nur in die Ideen investiert, die durch frühe Validierung bestätigt werden
  • Es gibt nur noch die wirklich wichtigen Features
  • Es wird der sogenannte Feature Creep vermieden (was ist eigentlich schneller, als Dinge nicht tun?)

Fazit

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”.

Bilder und sonstige Dankeschöns!

Zusammenspiel von Discovery und Delivery Zyklen

Share :

Related Posts

Agile Testing - eine Domäne von high performing Teams

Kleine Wasserfälle und ihr Einfluss auf die Performance Die Tester, Entwickler, Scrum Master, Product Owner unter euch, die diesen Artikel lesen, kennen das Problem: die Entwickler sind zwei oder sogar drei Wochen am Entwickeln, der Sprint nähert sich dem Ende. Noch muss die QA (“Quality Assurance”) das Inkrement als “done” abstempeln, bevor es offiziell wird. Und dann passiert es wieder: Im Inkrement wurde ein Fehler gefunden, es kommt zurück und die Suche nach den Bugs fängt an. In diesem Moment liegen bereits alle Nerven blank. Das Sprintziel ist gefährdet. Niemand weiß, wie lange es dauern wird und der Kunde wartet ungeduldig auf die neuen Features, die ihm mehrmals versprochen wurden. Wird wieder nachts gearbeitet, um das Sprintziel zu erreichen? Wird QA genug Zeit haben, um alle Tests auszuführen? Oder entscheidet sich das Team, den Sprint zu verlängern? Klingt wie eine Wahl zwischen Pest und Cholera. Dem agilen Manifest entspricht es in keinster Weise. Und leider haben wir solche Szenarios unzählige Male bei Kunden gesehen.

Read More

Agile Testing Manifesto

Schon einmal davon gehört? Während meiner Recherchen zu “Agile Testing” bin ich auf das Werk von Karen Greaves and Samantha Laing gestoßen. Das Agile Testing Manifesto ist eine Sammlung von Leitprinzipien für das Testen im Kontext der agilen Softwareentwicklung. Es zeigt uns, wie wir über Tests im agilen Kontext denken sollen und ist eine hervorragende Anleitung dafür, wie das Testen in einer agilen Umgebung angegangen werden sollte.

Read More