UX im Scrum Prozess – geht da was?

Bei PPI.X hat sich Scrum sowohl als Vorgehensmodell für die Entwicklung eigener Softwareprodukte als auch in Kundenprojekten bewährt. In vielen kurzen Iterationen von potenziell nutzbaren Produktinkrementen auf ein vollwertiges Produkt hinzuarbeiten, erscheint aus verschiedenen Perspektiven attraktiv:

• Wenige Regeln, leicht verständlich und schnell einführbar
• Kurze Kommunikationswege
• Hohe Flexibilität/Agilität durch adaptives Planen
• Hohe Effektivität durch Selbstorganisation
• Hohe Transparenz durch regelmäßige Meetings und Backlogs
• Zeitnahe Realisation neuer Produkteigenschaften beziehungsweise Inkremente
• Kontinuierlicher Verbesserungsprozess
• Kurzfristige Problemidentifikation
• Geringer Administrations- und Dokumentationsaufwand

Gleichzeitig haben wir den Anspruch, Software nutzerzentriert zu entwickeln: Im Idealfall starten wir im UX-Team früh mit der Nutzereinbindung, beispielsweise durch die Erhebung von kontextbezogenen Nutzeranforderungen, und lassen sie in die Konzeption einfließen – zum Beispiel durch Use Cases. Die Erkenntnisse werden in erste klickbare Prototypen übersetzt, deren Usability und UX an den potenziellen Usern verprobt und optimiert werden, bevor auch nur eine Zeile Code geschrieben wird. Wir skizzieren so benutzerfreundliche Bedienkonzepte und ein ansprechendes Design für unverwechselbare Softwareprodukte.

So sinnvoll die frühzeitige Nutzereinbindung klingt, ist sie doch gleichzeitig eine Herausforderung für den agilen Entwicklungsprozess: Wir haben auf der einen Seite einen eher wasserfallartigen Projektverlauf bei UX, der scheinbar unvereinbar mit dem agilen und iterativen Entwicklungsprozess auf der anderen Seite ist. Ich möchte mich im vorliegenden Beitrag mit der Herausforderung der Kombination der beiden Ansätze beschäftigen und ein Modell skizzieren, in dem die praktische Umsetzung funktionieren kann. Viel Spaß!

Ausgangslage

Um gleich offen und ehrlich zu sein: Wir haben uns zu Beginn unserer Integrationsbemühungen der beiden Disziplinen die eine oder andere „blutige Nase“ geholt. Naive Annahmen, nicht ausreichende Kommunikation und zu hohe Erwartungen sind unter anderem als Gründe zu nennen.
Zunächst scheint klar zu sein: Wenn ein Produkt auf Basis von Bedürfnissen und Anforderungen der (potenziellen) User entwickelt und Entwürfe mit ihnen getestet werden sollen, müssen Informationen und Daten zu der beziehungsweise den Nutzergruppen am Beginn der Produktion bekannt sein. Es besteht die Gefahr, dass bei einer sofort startenden Entwicklung ohne Wissen über die Nutzerbedürfnisse falsche und gegebenenfalls im Projektverlauf nur mit hohem Budgetaufwand wieder revidierbare Entscheidungen getroffen werden.

Längere Initialisierungsphase, dann Entwicklung nach Scrum?

In der Konsequenz könnte dies bedeuten, dass nach dem Kick-off das Projekt durch eine erste längere Initialisierungsphase gekennzeichnet ist. Das UX-Team führt User Research durch, entwickelt Ideen, erstellt Use Cases und User Stories, arbeitet an Konzept und Vision mit und überführt die Ergebnisse in Prototypen, zum Beispiel in Form eines Klickdummy-MVP.
Es klingt so, als wenn die Entwickler in dieser Phase zunächst nichts zu tun haben und auf das Konzept und die UX-Entwürfe warten müssten – also nach „Old-School-Wasserfall-Projekt“.

Lean UX lehrt uns, dass die Definition des Business-Problems, die Auseinandersetzung mit Zielgruppen und User Research, Bestandteil der ersten Sprints sind und durch das gesamte Scrum-Team durchgeführt werden, um früh zu lernen und Annahmen/ Hypothesen zu prüfen und anzupassen. Ganz ausdrücklich werden bisher bestehende Silos aus UXler und DEVler aufgelöst und gemeinsam als Scrum Team an diesen Themen gearbeitet. UX ist keine Tätigkeit, die nur zu Beginn bzw. ausgewählten Punkten eines Projektes geleistet wird, sondern findet permanent über alle Sprints statt. Operative Herausforderungen entstehen unter anderem, wenn die Rekrutierung und Terminierung der Nutzer für den User Research mehr Zeit in Anspruch nehmen als geplant. Im Sinne des agilen Vorgehens müssen bei Nichtbearbeitung im Sprint geplante Tasks zurück ins Product Backlog geschoben und neu priorisiert werden. Insofern spielt Erfahrung bei der realistischen Einschätzung von User-Research-Tasks für einen Sprint eine große Rolle. Dabei existieren keine getrennten Backlogs für UX und Dev, sondern UX-Aufgaben sind im Idealfall in allen relevanten Product Backlog Items integriert. Um sich dem Thema Zusammenarbeit zu nähern kann als erster Schritt die Arbeit mit einem gemischten Backlog sinnvoll sein (s. Abb. 1).

Dual Track Agile

Lean UX hat für dieses Vorgehen den Begriff Dual Track Agile geprägt. Die Idee arbeitet mit einem Team in zwei parallelen Tracks: dem Discovery Track und den Development Track.

Im Discovery Track arbeiten Product Owner und Usability Engineer zusammen daran, User Research durchzuführen, um Nutzungskontext, -ziele und -bedürfnisse der User systematisch zu erheben. Des Development Team und Stakeholder nehmen zumindest teilweise an den Research-Sessions teil, beraten das Discovery Team bei auftauchenden Fragen und unterstützen teilweise auch bei der Interviewdurchführung. Ergebnistypen dieses Tracks sind dann Context-of-Use- oder Customer-Jobs-Beschreibungen, Konzepte, Wireframes oder Prototypen, die als User Stories in den Development Track überführt werden (siehe Abb. 2). Die Ergebnisse des Discovery Tracks basieren auf Annahmen, die im weiteren Prozess validiert werden müssen und gegebenenfalls zu Anpassungen am Konzept führen.

Der Development Track (auch Delivery Track) umfasst die Umsetzung der im Konzept geplanten Features zum eigentlichen Produkt. UX unterstützt hier das Entwicklungsteam unter anderem mit Usability Tests fertiggestellter Features. Die Rückmeldungen aus den Tests werden dann wieder vom Entwicklerteam umsetzt, sodass eine kontinuierliche Verbesserung der bereits entwickelten und noch zu entwickelnden Features sichergestellt ist.

Zusammengefasst kann man sagen, dass die Disziplinen UX und DEV in einem cross-funktionalem Team ab Sprint 1 verzahnt zusammenarbeiten. Das Projektvorgehen ist dabei zweigleisig (s. Abbildung 2). Da im Discovery Track Annahmen erarbeitet werden, 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. Während des gesamten Prozesses ist räumliche Nähe und ein ständiger Austausch der Parteien ein Muss, um schnell auf mögliche Änderungen reagieren zu können, denn zwei Tracks bedeuten nicht zugleich zwei Teams. Dem agilen Mindset folgend ist das gesamte Team (natürlich mit verschiedenen Schwerpunkten) für den Erfolg eines Produktes verantwortlich und muss sich als Konsequenz in beiden Tracks wiederfinden können.

Praktische Erfahrungen

In der Zusammenarbeit hat sich gezeigt, dass der kurzfristige Zugriff auf Nutzer je nach Zielgruppe eine Herausforderung darstellen kann: Bei einem Projekt, in dem eine Business Software erstellt wird, müssen immer wieder Kollegen aus dem Tagesgeschäft freigestellt werden, um für Interviews im Projektverlauf zur Verfügung zu stehen. Bei B2C-Anwendungen müssten Nutzer entweder für einen längeren Zeitraum bereit sein, immer wieder für Tests zur Verfügung zu stehen, oder permanent neue User aus der Zielgruppe rekrutiert und für Interviews terminiert werden. Ansätze, die mit vorrekrutierten Online-Pools von Testpersonen arbeiten, die dann über Links die Programmierfortschritte testen, können auf niedrigem Niveau Erkenntnisse liefern, sind aber nicht mit dem Erkenntnisgewinn aus persönlichen Interviews zu vergleichen. Der Aufwand für Onlinetests ist ebenfalls hoch.

Nicht selten unterschätzen Auftraggeber den Aufwand von UX und User Research und messen der Disziplin einen geringen Beitrag zum ROI bei. Im Ergebnis beobachten wir, dass der UX- und User-Research-Anteil in Projekten auf ein kleines Maß zusammengestrichen wird. Das birgt die konkrete Gefahr in sich, dass schon in der Konzeption und später in der Entwicklung Nutzerbedürfnisse nicht ausreichend berücksichtigt werden und kein optimales Produkt gelauncht wird. Es steht zu erwarten, dass mit steigender Anzahl von agilen Entwicklungsprojekten auch der Wertbeitrag von UX zunehmend höher eingeschätzt werden wird.