Als agiler Usability Engineer beschäftigt mich häufig die Frage: Scrum und Usability – Dreamteam oder nicht? Erste Antworten dazu habe ich bereits in dem Blogartikel “Passen Agilität und Usability Engineering wirklich zusammen?” gegeben. Eine weitere interessante Möglichkeit der Integration von Usability-Methoden und -Prozessen in einen agilen Entwicklungsprozess bietet Dual-Track Scrum.
Dual-Track Scrum: Ursprung und Idee
Dual-Track Develoment – diese Methode durfte ich während eines Product-Owner-Workshops bei Jeff Patton und Jeff Gothelf kennenlernen. Ursprünglich entwickelt hat die Idee der dualen Tracks Desiree Sy in ihrem Paper “Adapting Usability Investigations for Agile User-centered Design” von 2007. Sie beschreibt Tracks darin als Phasen, die im gesamten Entwicklungszyklus vom Team durchlaufen werden. Man könnte die beiden Tracks auch als parallel laufende Wege bezeichnen, in denen kollaborativ zusammengearbeitet wird.
Ein vielversprechender Ansatz, wie ich finde, der die Integration von UX in den agilen Entwicklungsprozess ermöglicht und den Usability Engineer miteinbezieht. Im Scrum-Umfeld bezeichnet man die Methode der dualen Tracks als Dual-Track Scrum oder allgemeiner als Dual-Track Agile.
Die Idee hinter dem Dual-Tracks-Prinzip in Scrum ist einfach: Tatsächlich passiert es immer wieder, dass zwar unter dem Deckmantel von Scrum oder anderen agilen Methoden gearbeitet wird, die Entwicklung jedoch trotzdem nach dem Wasserfallprinzip abläuft. Die Anforderungen werden eingekippt, ein Design wird erstellt, das Feature wird entwickelt und getestet. Für jede Aktivität sind andere Parteien zuständig (Product Owner, Designer, Entwickler, Tester), wodurch sich eine sequentielle Arbeitsweise ergibt und starke Abhängigkeiten entstehen. Um genau diesem Problem entgegen zu wirken, schlägt auch Jeff Patton zwei parallele Tracks vor – den Discovery Track und den Development Track.
Discovery und Development: zwei parallele Tracks
Beginnen wir mit dem Discovery Track: Dieser Track ist im Vergleich zum klassischen Scrum-Vorgehen neu. Allerdings nicht in dem Sinne, dass er bei Scrum nie berücksichtigt wurde, sondern neu in der Wichtigkeit, die ihm zugeschrieben wird. Im Discovery Track arbeiten Product Owner und Usability Engineer eng zusammen, um die Ziele und Bedürfnisse der Nutzer zu erfassen. Der Rest des Entwicklungsteams und auch die Stakeholder agieren als Berater, um auftauchende Fragen unmittelbar beantworten zu können. Das Ergebnis dieses Tracks sind dann Konzepte, Prototypen und Erfahrungen aus Research-Tätigkeiten, die beispielsweise in Form von User Stories in den Development Track übergeben werden (siehe Abbildung unten). Diese Discovery-Aufgaben sind prinzipiell als reine Hypothesen zu betrachten.
Dual-Track Scrum nach Jeff Patton
Der Development Track, oft auch als Delivery Track bezeichnet, beinhaltet hingegen die eigentliche Entwicklung der geplanten Features. In diesem Track wird aus den zuvor abgestimmten Konzepten das wirkliche Produkt. Während dieser Zeit unterstützt der Usability Engineer das Entwicklungsteam zum Beispiel in Form von User Tests. So kann eine kontinuierliche Verbesserung der bereits entwickelten und noch zu entwickelnden Features sichergestellt werden.
Der Discovery und Deveploment Track arbeiten demnach Hand in Hand, wie in der obigen Abbildung zu sehen. Im Discovery Track kann es vorkommen, dass Ideen wieder verworfen werden oder sich andere Lösungen herauskristallisieren. Auch diese Art von Erkenntnissen sind wertvoll und sollten in die weitere Arbeit einfließen. Wichtig ist, dass zwei Tracks nicht zugleich zwei Teams bedeuten. Jeff Patton fasst diese Aussage sehr schön in wenigen Worten zusammen: “It’s Dual Track, not Duel Track”. Wenn laut agilem Mindset das gesamte Team für den Erfolg eines Produktes verantwortlich ist, dann muss sich auch das gesamte Team (natürlich mit verschiedenen Schwerpunkten) in diesen beiden Tracks wiederfinden können.
Die Rolle des Usability Engineers
Wenn wir uns nun den Usability Engineer und seine Aufgaben in diesem Prozess genauer anschauen, fällt auf, dass er in beiden Tracks eine definierte Rolle übernimmt. Im Discovery Track ist er, zusammen mit dem Product Owner, zuständig für die Anforderungserhebung, das Sammeln von Informationen und die Konzeption. In dieser Phase lassen sich jedoch meistens nicht alle Fragen gänzlich klären. Detailfragen, wie z. B.: “Wie soll diese Animation aussehen?”, oder die Prüfung von technischen Machbarkeiten lassen sich oft erst während der Entwicklung beantworten. Im Development Track wird der Usability Engineer daher eher zum Berater für das Entwicklungsteam. Unterteilt man das Ganze in Sprints, dann könnten die Usability- und UX-Tätigkeiten folgendermaßen aussehen:
- Kommender Sprint (Discovery Track): Konzeption und Designphase für anstehende Features
- Aktueller Sprint (Development Track): UX-Beratung bezüglich aktuell entwickelter Features
- Vergangener Sprint (Discovery Track): Evaluation und Testing der vergangenen Features
Diese Aufteilung der Arbeit funktioniert jedoch nicht immer. Wie in vielen Theorien wird auch hier der Ideal-Fall angenommen. Es gibt immer wieder Projektsituationen, in denen intensivere Usability-Arbeiten benötigt werden, zum Beispiel zu Beginn eines Projektes oder auch zum Ende hin. In solchen Fällen sind die Konzeptions-, Beratungs- und Evaluationsphasen nicht immer gleichermaßen einzuhalten. Da laut Dual-Track jedoch sowieso der gesamte Entwicklungszyklus betrachtet wird, ist dies nicht weiter schlimm. Vor allem die Discovery-Arbeit ist nicht zu jedem Zeitpunkt gleich verteilt.
Voraussetzungen für einen erfolgreichen Dual-Track
Auch wenn das Prinzip gar nicht so kompliziert klingt, kann eine erfolgreiche Durchführung scheitern, sobald folgende Punkte nicht beachtet werden:
- Discovery und das damit verbundene Erfassen der Bedürfnisse sind ein notwendiger Bestandteil der Produktentwicklung – doch nur wenn ein Unternehmen diese Meinung auch wirklich vertritt, kann Dual-Track Scrum funktionieren.
- Der Fortschritt sollte für das gesamte Team sichtbar gemacht werden – Ergebnisse aus dem Discovery Track müssen kommuniziert werden (dazu kann man z. B. einen festen Zeitraum im Review einplanen).
- Den Erfolg messen, daraus lernen und Schlüsse ziehen – auch nach der Produktauslieferung.
- Es gibt zwar zwei Arten von Arbeit (Discovery und Development), jedoch nicht zwei Arten von Teams – es ist immer noch das eine Team, das für die Auslieferung des Produktes verantwortlich ist. Daher sollte auch jeder in den Discovery Track miteinbezogen werden.
Mit Sicherheit gibt es noch eine Menge weiterer Voraussetzungen – zum Beispiel das richtige Mindset oder die Kenntnis der notwendigen Methoden – doch die oben genannten bilden für mich den Kern einer erfolgreichen Dual-Track Scrum Verwendung.
Ob diese Methode für ein Projekt in Frage kommt und sinnvoll ist, kann man nur von Fall zu Fall entscheiden. Ich bin überzeugt von der agilen Arbeitsweise und vom Usability Engineering. Dual-Track Scrum ist eine weitere Idee, die beiden Disziplinen zu vereinen.
Wenn du gerne mehr über das Thema Usability Engineering im Scrum-Prozess erfahren möchtest, findest du in unserem Blog mehr Infos dazu. Und wenn du keinen Artikel mehr verpassen möchtest, kannst du dich direkt registrieren.
Kommentare