Dual Track Scrum
In der Praxis gar nicht so einfach!
Design- und Entwicklungsprozesse in einem agilen Projekt vereinen? Da muss es doch schon etwas geben! Das haben wir uns auch gedacht und sind dabei auf den Dual Track Scrum gestoßen. In diesem Artikel berichten wir von unseren Erfahrungen, wie wir unsere Zusammenarbeit zwischen Designer- und Entwickler:innen in agilen Projekten optimiert haben und auf welche Hürden wir gestoßen sind.
Unsere Rahmenbedingungen
Ob B2B, Produktentwicklung oder etwas völlig anderes: Jedes Unternehmen arbeitet unter anderen Bedingungen, daher können unterschiedliche Faktoren den Projektablauf beeinflussen. Hier ein kleiner Einblick, wie die Rahmenbedingungen in unseren Projekten aussehen:
Überwiegend arbeiten wir in einem Spannungsfeld von agilen Festpreisprojekten. Oftmals gehen wir nach Scrum vor und haben dabei ein festes Projektbudget.
Mit Scrum kommt das "Product Backlog" einher, wo Anforderungen an das Produkt festgehalten werden. Wir halten diese Anforderungen als sogenannte User-Stories fest [1]. In bestimmten Zeiträumen (Sprints) nehmen wir uns einige User-Stories vor und setzen diese in einer lauffähigen Software um. Am Ende eines Sprints stellen wir die umgesetzten User-Stories den Projektbeteiligten vor, holen Feedback ein und lassen diese in der weiterführenden Entwicklung in die Software einfließen.
Zu Beginn eines Sprints arbeiten Designer:innen an der Konzeption und Visualisierung einer User-Story. Dies geschieht oft in Form von Mockups. Auf dieser Basis wird Feedback von den Nutzer:innen eingeholt und das Mockup ggf. angepasst. Danach, etwa bei der Sprintmitte, können die Entwickler:innen mit der Umsetzung starten.
Diesen Lebenszyklus haben wir zuerst auch 1:1 versucht, so zu durchleben. Wir sind dabei allerdings auch auf Probleme gestoßen. Wenngleich natürlich für eine Anforderung gleichermaßen Design als auch Entwicklung benötigt werden und es auch schön wäre, dies in einer User-Story beides zu erledigen, erwies sich eben genau das als eines der größten Probleme. Der Sprint startet, die Designer:innen wollen designen, wollen Feedback einholen und integrieren und die Entwickler:innen wollen natürlich entwickeln – Sie müssen aber warten bis der Designprozess beendet ist.
Design und Entwicklung in einer User-Story im selben Sprint – ein Desaster.
Dieser Zustand führte schnell zu unangenehmen Leerläufen und zu einem erhöhten Stresslevel und Frustration im Projektteam. So entstand das irrtümliche Gefühl, dass Design im Rückstand wäre und dass nicht genügend Zeit für die Umsetzung übrig bliebe. Oftmals wurde der Designprozess aus Zeitnot verkürzt, was sich in der Regel zu einem späteren Zeitpunkt bemerkbar machte.
Unsere Erfahrung daraus: Design und Entwicklung in einer User-Story im selben Sprint abwickeln zu wollen war das reinste Desaster. Doch zum Glück ist das ein verbreitetes Problem und eine Lösung war in greifbare Nähe: der Dual Track Scrum.
Der Dual Track Scrum
Diese Technik ist auch gar nicht so neu und wurde bereits ausführlich beschrieben [2]. Die Theorie in einem Bild:
Die Idee ist recht simpel: Hier wird nun versucht, den Designprozess ebenso mit einzuplanen und dies optimalerweise auch ein Stück vorläufig, sodass der Designprozess ausreichend Zeit und Raum in einem Sprint einnehmen kann. Der vollständige Output kann zum Abschluss des Sprints an die technische Implementierung, also die Entwicklung, übergeben werden. Der Lebenszyklus unserer User-Stories im Sprint sah nun so aus:
In "Sprint n" beginnen wir mit den Designaufgaben. Nach dem Einarbeiten von Nutzerfeedback ist optimalerweise "Sprint n" abgeschlossen und der nachfolgende "Sprint n+1" beginnt mit der Entwicklung. Damit allein lassen sich Leerläufe und Stress schon deutlich reduzieren [2]. Wir stellten jedoch schnell fest, das dies immer noch nicht alle Probleme lösen konnte. Denn es gab noch ein wesentliches, nicht zu unterschätzendes Detail was die User-Stories angeht: Nicht jede User-Story ist gleich! Einige sind klar abgegrenzt, nicht zu komplex und schnell zu bewältigen, z. B. das Anpassen von Übersetzungen. Andere sind echte Herausforderungen mit vielen Umsetzungsmöglichkeiten. Als Beispiel nehmen wir folgende Anforderung einer User-Story an:
"Ich als Fahrgast möchte mein Busticket kaufen können."
Eine einfache Tätigkeit auf den ersten Blick, aber: Ein Busticket kann online am Computer oder über ein Smartphone gekauft werden. Es kann analog auch als gedrucktes Ticket an einer Bushaltestelle gekauft werden. Für jeden dieser aufgezählten Pfade gibt es auch verschiedene Arten, diese mit digitalen Mitteln zu unterstützen. Mit anderen Worten: Die User-Story, die es zu bewältigen galt, hat plötzlich einen größeren Umfang an Komplexität und Anforderungen erhalten. Nicht selten stellten wir fest, dass eine aufgeschriebene, eingeplante und scheinbar überschaubare User-Story sich auf einmal als ein Riesenthema entpuppte. Und dass hier noch weitaus mehr nötig war, als ein Mockup zu erstellen und dieses abzusprechen. Nein, es war richtige Forschungsarbeit nötig, um zu verstehen, wie man das Problem überhaupt fachgerecht und nutzerfreundlich lösen könnte. Man ahnt es nun schon – dies führte dann an dieser Stelle wieder zu "neuen alten Problemen". Was also tun?
Die Discovery-Arbeit
Ziel ist es, die Komplexität einer User-Story so herunterzubrechen, dass sie innerhalb eines Sprints sowohl in Form eines Mockups als auch bei der Implementierung umsetzbar ist. Die Discovery-Arbeit oder auch Anforderungsermittlung beschäftigt sich genau mit dieser Thematik. Es gibt unterschiedliche Werkzeuge dafür: User Research, Domain Storytelling [3] und noch vieles mehr! Zur Durchführung wird ein Meeting geplant, um mit den zuständigen Projektbeteiligten die Discovery-Arbeit durchzuführen. Einen gemeinsamen Termin mit allen zur User-Story relevanten Projektmitgliedern zu finden ist zwar nicht einfach, aber notwendig.
Da die Discovery-Arbeit danach in den Design-Track überläuft, ist es naheliegend, dass Designer:innen auch die Discovery-Arbeit machen und anschließend das fertige Mockup und Konzept an die Entwickler:innen übergeben. Diese Annahme ist jedoch falsch!
Das Ziel sollte doch sein, dass alle für die Endnutzer:innen arbeiten!
Bei dieser Trennung bekommt das Entwicklungsteam keine direkten Informationen der Anwender:innen mehr mit. Die Designer:innen tragen die alleinige Verantwortung für die Nutzerzufriedenheit und es fühlt sich irrtümlicherweise so an, als ob das Entwicklungsteam nur für das Design-Team arbeitet und nicht mehr für die tatsächlichen Anwender:innen. Das Ziel sollte jedoch sein, dass alle für die Endnutzer:innen arbeiten und somit alle die Verantwortung für die Nutzerzufriedenheit übernehmen. Damit sollten alle an der Discovery-Arbeit beteiligt sein. Es soll ein gemeinsames Wissen und eine gemeinsame Verantwortung aufgebaut werden, um Missverständnisse zu vermeiden. Das gilt auch für weitere Projektbeteiligte wie Software-Architekten, Product Owner Projektleiter:innen usw. Wie Jeff Patton bereits sagte:
Fazit
In diesem Artikel haben wir unsere Erfahrungen, Herausforderungen und Vorteile im Projekt mit dem Dual Track Scrum mit Euch geteilt. Wir haben auch festgehalten, welche Anpassungen wir getätigt haben, um uns den Prozess anzueignen. Damit ist die Reise aber noch lange nicht vorbei! In unterschiedlichen Projekten haben wir unterschiedliche Erfahrungen damit gemacht und werden sie auch weiterhin machen. Mit jedem neuen Projekt kommen neue Herausforderungen auf uns zu. Also werden wir weiter zielstrebig auf eine gute Zusammenarbeit zwischen Designer- und Entwickler:innen im Projekt hinarbeiten. Denn wir ergänzen uns gegenseitig.
Apropos "gegenseitig": Wir sind natürlich auch daran interessiert, wie es bei Euch läuft! Falls Ihr Interesse an einem Austausch habt oder Eure Erfahrungen mit uns teilen mögt, nehmt gerne Kontakt auf!
- Max Rehkopf, 2022: User stories with examples and a template
- Desirée Sy, 2007: Adapting Usability Investigations for Agile User-centered Design
- Stefan Hofer & Henning Schwentner, 2022: Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software
- Jeff Patton, 2017: Dual Track Development is not Duel Track
