Ausführliche nutzerzentrierte Konzeption und agiles Vorgehen stehen scheinbar im Widerspruch zueinander. Wenn man aber bereit ist ein UX (User Experience) Konzept in seinem Detailgrad Schritt für Schritt zu entwickeln und frühzeitig Prototypen einsetzt, ist UX Design nahtlos und ohne “faule Kompromisse” in agile Entwicklungsprozesse integrierbar.

Laut agiler Entwicklungtheorie wird zu Beginn des Projektes der Produkt-Backlog mit Epics und User Stories (Stories) gefüllt basierend auf den Anforderungen der Produktvision. Welche Funktionalität letztendlich umgesetzt wird, entscheidet das Team fortlaufend am Beginn eines jeden Sprints. In jedem Sprint soll ein Stück Software konzipiert, spezifiziert, implementiert, getestet und deployed werden. Die Dokumentation wird absolut minimal gehalten.

Wenn wir UXler UCD (User Centered Design) stilgerecht einsetzen, beginnen wir mit der Erhebung der Anforderungen unter Einsatz diverser UCD Methoden, wie z.B. Contextual Inquiry etc. Diese Anforderungen lassen wir in einen Prototypen, in Storyboards und Szenarios einfliessen, die uns letztendlich ein Konzept der Interaktion zwischen Nutzer und System visualisieren. Wir betrachten ein Gesamtbild aus System, Nutzer Task und Umfeld. Dieses Gesamtbild zu schaffen ist zeitaufwendig und von vielen Abhängigkeiten geprägt.

Viele UX Spezialisten machen sich deshalb Sorgen und verweisen auf mögliche Konflikte zwischen UCD und agilen Prozessen:

  • In grösseren Projekten ist es fast unmöglich UX Konzeption und Design im selben Sprint auszuführen wie die Entwicklung, geschweige denn alles zu testen (inkl. Usability Tests).
  • In SCRUM gibt es kein “Gesamtbild” ausser dem Backlog.
  • Einen übergreifenden horizontalen Prototyp kann es angeblich in einem agilen Prozess nicht geben, weil es vorab keine Spezifikation gibt (ein “Vorab” existiert nicht!).
  • Ein UX Konzept kann nicht in einzelne Stories runtergebrochen werden, ohne dass die Konsistenz darunter leiden wird.
  • Nutzerforschung ist zeitintensiv und hat sehr viel Abhängigkeiten zu externen Stakeholdern. Darum ist sie “time-boxed” kaum durchführbar.

Haben diese Aussagen und Bedenken ihre Berechtigung? Ist es so, dass UX nur schwer in agile Prozesse eingebunden werden kann? Muss man die UCD Methodik überdenken und anpassen? Muss man im agilen Vorgehen Kompromisse eingehen?

 

Versuch eines Lösungsvorschlag

Tatsächlich scheint es einige Konflikte zwischen der agilen Welt und den angewandten UCD Methoden zu geben. Ich möchte hier einen Versuch starten und aufzeigen, was ich aufgrund der Erfahrung aus SCRUM Grossprojekten gelernt und als UX Spezialist angewendet habe.

Wir gehen einmal davon aus, dass vor Projektbeginn eine Vorstudie gemacht wurde, erste Stakeholder-Gespräche geführt wurden und ein Projektvision (inkl. entsprechendes Dokument) bereits besteht. Die Anforderungen an das System wurden grobgranular abgesteckt und das Backlog mit ersten Epics gefüllt. Es wurden vielleicht sogar hypothetische Personas erarbeitet.

 

Ansatz 1:

Sprint 0 ist keine Option

Viele UX Experten empfehlen einen so genannten Sprint 0 vor der eigentlichen Sprintfolge einzuschieben und dort das gesamte UX Konzept, das Design und den Prototypen zu erstellen.

Die Erfahrung aus Grossprojekten hat gezeigt, dass in einem entsprechenden Umfeld ein solcher Sprint 0 bis zu einem Jahr dauern kann. Das Business schlägt in einem solchen Zeitraum zu viele Nägel ein. Ein echtes agiles Vorgehen ist dann kaum mehr möglich. Ich will aber nicht ausschliessen, dass ein Sprint 0 für kleinere überschaubare Projekte durchaus sinnvoll sein kann, wenn wie gesagt die Grenzen des Projektes dadurch nicht zu eng abgesteckt werden.

 

Ansatz 2:

Konzeptionelle Epics und User Stories

Für den ersten Sprint erarbeitet der Product Owner nun mit dem Team konzeptionelle Epics und User Stories und füllt sie in den Backlog. Man kann diese Stories nicht ganz nach dem klassischen Muster (“Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen> zu erreichen”). Man kann aber für diese ersten Sprints im Projekt die Entwickler und Business Analysten (inkl. UX) in die Rollen stecken und Ziele an das Projekt formulieren.

Für die UX Spezialisten wird es in den ersten Sprints (2-5) darum gehen, durch diverse Erhebungsmethoden (Contextual Inquiry, Interviews, etc.) die Personas zu verifizieren, den Backlog mit weiteren Anforderungen zu füllen und in einem ersten High Level Prototype zu visualisieren (Wireframes, Scribbles etc.).

Gleichzeitig entwickeln die System Architekten und Entwickler einen vertikalen Prototypen und identifizieren ihrerseits wichtige Anforderungen, die ebenfalls in den Backlog einfliessen.

Mit diesem Stand werden nun weitere Stories geschnitten und die folgenden Sprints geplant, in denen Story um Story die Funktionalität detaillierter analysiert, spezifiziert, implementiert, getestet und ausgeliefert werden.

 

Einen Sprint voraus

In Projekten, in denen das Requirements Engineering mit vielen Abhängigkeiten verbunden ist und grosser Analysebedarf besteht, ist es ratsam, der Business Analyse (Requirements Engineers und UX Spezialisten) einen Sprint Vorlauf zu geben.

Ein Beispiel: Im Sprint 3 wird die Story x konzipiert und evt. auch ausgestaltet (Visual Design). Implementiert, getestet und ausgeliefert wird sie dann in Sprint 4, in dem bereits die Story y für Sprint 5 konzipiert wird. Ich nenne diese Sprint-Teile “Prep” (Perparation) und “Dev” Development. In den “Prep-Sprints” werden die Anforderungen und der Prototyp verfeinert und angepasst. (Mehr zur Wichtigkeit von Prototypen lesen Sie hier)

 

Fazit

Ein solches Vorgehen hat sich in meinem Umfeld sehr gut bewährt. Es bedingt aber, dass die Konzeption in den ersten Sprints auf einem hohen Level stattfindet und auch der Prototyp grob umrissen wird.

Die Vorteile dieser Vorgehensweise kann man wie folgt zusammenfassen:

  • Das Projekt kann in gleichlangen 2-4 Wochen-Sprints durchgeführt werden.
  • Das SCRUM Team (BAs, UXler und Entwickler) arbeitet von Anfang an zusammen.
  • Es ist möglich, eine Gesamtsicht in einer frühen Projektphase zu erarbeiten ohne zu weit in die Details zu gehen.
  • Ein Prototyp kann als Spezifikationsgrundlage durch alle Sprints “mitgezogen” werden.
  • Ein UX Konzept kann konsistent und kontinuierlich aufgebaut werden.
  • UCD Erhebungsmethoden wie Contextual Inquiry können in den ersten Sprints geplant, ausgeführt und ausgewertet werden.