UX im Scrum-Team – Kann es Liebe werden?
· Oliver
Es gibt keinen Zweifel, dass Scrum ein großartiges Framework für agile Softwareentwicklung ist. Es bietet das richtige Format und die passenden Werkzeuge, um Dinge schnell fertigzustellen und von den eigenen Fehlern zu lernen, während man arbeitet.
Ohne Überraschung ist Scrum also auch der Prozess der Wahl bei jobvalley.tech. Unser Problem war allerdings, dass wir nie einen guten Weg gefunden haben, wie wir UX ins Scrum-Team integrieren können. Bis jetzt!
Geschichtsstunde
Damals in den vorzeitlichen Tagen der Softwareentwicklung gab es noch kein Scrum. Die Entwicklung geschah in einem Prozess, den man gern als „Wasserfall” bezeichnet. Im Grunde kann man ihn sich wie eine gerade Zeitlinie vorstellen, bei der man sich am Anfang Zeit nimmt, um die Spezifikationen aufzuschreiben, die nahezu jedes Detail des zu entwickelnden Features oder der Software beschreiben. Dieses Spezifikations-Dokument wird dann an den Designer übergeben, der das Interface und die gewünschten Interaktionen mit dem Feature/der Software entwirft. In einer späteren Phase werden das Spezifikations-Dokument und die ausgearbeiteten Designs von den Entwicklern übernommen, um die Vorgaben peinlichst genau in „Code zu gießen”, sodass das Feature/die Software veröffentlicht werden kann und wird.
Beim Wasserfall gibt es keinen Weg zurück und das Feature/die Software wird erst veröffentlicht, wenn alles fertiggestellt ist. Ein mögliches User-Testing geschieht hier immer erst, wenn es fertig und veröffentlicht ist.
Klingt gut? Naja, vielleicht wenn du immer noch ein Fax als dein Haupt-Kommunikationsgerät benutzt.
Scrum eilt zur Hilfe
Scrum (und andere agile Herangehensweisen an Softwareentwicklung) änderten das. Das neue Kredo war „veröffentliche früh, veröffentliche oft”. Spezifikations-Dokumente und bis ins Kleinste ausgearbeitete Designs wurden durch kurze Konzepte von Teilen der Software und Wireframes ausgetauscht. Design ist nun Teil des Entwicklungsprozesses und ihm nicht mehr vorgelagert. Das Design entwickelt sich stückweise, ebenso wie die Features in der Software auch.
Und genau da liegt das Problem. UX funktioniert anders. UX zielt darauf ab, im Voraus zu planen und detaillierte Konzepte mit ausgearbeiteten Designs zu verfassen, die dann von den Entwicklern realisiert wurden. Zumindest war das früher so.
Versucht man, diese Konzepte und Designs mit in den agilen Sprints zu verfassen und zu entwerfen, führt das dazu, dass das Entwicklungsteam oft auf Input warten muss, bevor es an Stories und Features arbeiten kann.
Wir haben also ein Problem: UX und Scrum passen nicht wirklich zusammen. UX kann also kein Teil des Scrum Prozesses sein. Oder eben doch?
Fallstricke
Wie eben bereits erwähnt funktioniert es nicht einfach so, UX in den Scrum Prozess zu integrieren, ohne den UX-Prozess vorher anzupassen.
Die Regeln von Scrum auf den UX-Prozess anzuwenden funktioniert aber leider auch nicht:
Es ist wichtig, eine konzeptionelle Phase zu haben, bevor man ein Feature implementiert. Das verschlingt Sprint-Zeit, in der das restliche Team warten muss.
Diese Konzeption zu überspringen und Dinge einfach auszuprobieren und zu iterieren, kann funktionieren, aber man riskiert das Bild vom großen Ganzen der gewünschten User Experience auf dem Weg zu verlieren.
Über die Konzeption und das Design „drüberzuhuschen”, um das Feature im Sprint fertigzustellen und dabei eine „minimal viable UX” zu akzeptieren, kann deinem Produkt schaden.
Der agile Wasserfall?
Man könnte UX also die Konzepte ausformulieren und die Designs entwerfen lassen, bevor das Entwicklungs-Team mit seiner Arbeit loslegt. Und die Entwickler könnten die Konzepte dann in ihren gewohnten Sprints einfach umsetzen. Richtig?
Nunja, das ist, was man einen „agilen Wasserfall”, oder „Agilefall” nennt. Man würde hierbei agile Methoden nutzen, die aber von einem Wasserfall-Prozess beschränkt sind, den Scrum ja in erster Linie abschaffen will.
Lean UX
Ein Ansatz, um diese Problematik anzugehen, wäre, einen Blick auf Lean UX zu werfen. Lean UX verändert den Weg, wie man Probleme aus einer UX-Perspektive angeht. Anstatt erst tief in die Problematik einzutauchen und dann eine Lösung dafür zu entwickeln, schaut man sich nun das Problem an und trifft Annahmen dazu. „Es würde funktionieren, wenn wir A durch B tauschen” oder „Der User wird C besser als B verstehen”. Lean UX funktioniert, wenn man bereits ein gutes Verständnis seiner Nutzerbasis und ein gutes Bauchgefühl hat.
Man nimmt einfach die aufgestellte Annahme und unterzieht sie einem Test. In Form eines Papier-Prototypen, eines funktionierenden Clickdummys, oder sogar in Form eines ausgearbeiteten Features, das während eines Sprints als funktionierendes Inkrement designt und entwickelt wird. Danach rekapituliert und validiert man seine Annahme und iteriert im nächsten Sprint über die Lösung, um diese besser zu machen.
Das Problem mit Lean UX ist leider erneut, dass man riskiert, der User Experience zu schaden, indem man das falsche Feature veröffentlicht. Sadface.
UX as a Service
Eine andere Herangehensweise, die wir für uns evaluiert haben, ist ein separates Team von UX Designern und Architekten, die UX als einen Service für die Entwicklungsteams sehen, die um ihre Hilfe bitten.
Das kann sicherlich funktionieren, aber wir trafen die Erkenntnis, dass es keine gute Idee für uns ist, wenn die UX Designer kein Teil des Entwicklungsteams sind. Schlüsselteile des wichtigen Fachwissens und Informationen über die bisherige Entwicklung gehen verloren und das macht es ungemein schwieriger, gute Produkte Hand in Hand zu entwicklen. Immer noch Sadface.
Wie man den richtigen Workflow findet
Jetzt haben wir wirklich genug über die Probleme gesprochen, die es verursacht, wenn man UX in den Scrum-Workflow integrieren möchte. Aber wie sieht es mit der Lösung aus?
Wir haben nahezu zwei Jahre gebraucht, um für uns den richtigen Weg zu finden. In dieser Zeit haben wir mit dutzenden anderer Scrum-Teams, Agenturen und User Experience Designern über deren Prozesse und Wege gesprochen, die beiden Welten miteinander zu verbinden.
Ohne große Überraschung hat sich gezeigt, dass es nicht die eine perfekte Lösung gibt. Verschiedene Teams verfolgen verschiedene Ansätze. Die Herangehensweise geht dabei von der simplen Akzeptanz, dass UX kein Teil des Scrum-Prozesses sein kann und daher ein eigenes Team bilden muss, bis hin zur Rückkehr in einen eher wasserfallartigen Prozess, damit es funktioniert.
Wir wollten das einfach nicht akzeptieren. Also haben wir weitergeschaut. Und schlussendlich haben wir die richtige Kombination aus Werkzeugen und Methoden gefunden, um unser Ziel zu erreichen!
Ich gehe weiter unten auf die Details ein, aber um es zusammenzufassen: Unsere Lösung ist ein „Dual-Track-Agile”-Ansatz mit einer Discovery- und einem Delivery-Track, kombiniert mit gestaffelten Sprints, in denen die UX Designer verschiedene Aufgaben verfolgen und Verantwortungen haben – je nach dem, in welcher Phase sich der Sprint gerade befindet. Dazu kommen „Design Spikes” für unsichere UX-Herausforderungen.
Dieser Workflow gibt uns die Möglichkeit, UX tief in den Scrum-Workflow zu integrieren, ohne die Vorarbeit und Planung der User Experience vor der eigentlichen Entwicklung zu vernachlässigen.
Dual Track Agile
Der erste magische Begriff ist „Dual Track Agile”. Im Grunde genommen verändert es den Scrum-Workflow von einem durchgehenden Gleis in der kurzfristigen Roadmap hin zu zwei Gleisen, die parallel laufen.
Discovery Track
Der „Discovery Track“ wird größtenteils vom Product Owner und dem User Experience Designer genutzt. Beide arbeiten eng zusammen daran, die Bedürfnisse und Wünsche der Nutzer der geplanten Software oder des geplanten Features herauszufinden. Der Rest des Entwicklungsteams ebenso wie die Stakeholder und Nutzer agieren in dieser Phase als Berater, sobald Fragen auftauchen.
Dieses Gleis enthält die gesamte User Research und Konzeption des Features, also zum Beispiel User Story Maps, Wireframes etc. bis hin zur Erstellung von einfachen bis komplexen Prototypen.
Die Erkenntnisse und Konzepte dieser Phase werden dann kontinuierlich in den „Delivery Track” in Form von User Stories, Tickets, Konzepten und Prototypen, inklusive der Resultate der Interviews und Usertests mit den Stakeholdern, übergeben.
Delivery Track
Das zweite Gleis, der „Delivery Track”, kümmert sich um die Entwicklung des geplanten und abgestimmten Features. Hier wird aus den Konzepten ein reelles Produkt.
Wenn du „klassisches” Scrum betreibst, dann ist dies aktuell dein einziges Gleis.
Die Rolle beider „Tracks”
In beiden Gleisen hat UX eine definierte Rolle. Während die UX Designer und Architekten im „Discovery Track” sehr eng mit dem Product Owner zusammen arbeiten, haben sie auch ihre klare Aufgabe im „Delivery Track”.
Da die Aufgabe des ersten Gleises darin besteht, Informationen zu sammeln und Konzepte im Rahmen des Sprints zu verfassen und diese zu übergeben, bleiben immer noch Detailfragen ungeklärt und Fragen unbeantwortet, die man während der Entwicklung bedenken muss. Zum Beispiel die Details einer Animation einer Interface-Komponente.
Daher ist der UX Designer im zweiten Gleis eher eine Art Berater für das Entwicklungsteam.
Gestaffelte Sprints
Die Hauptaufgaben von UX in beiden Tracks sind dabei immer die gleichen. Sie bauen sich in den ersten Sprints nach und nach auf, werden aber nach drei Sprints konsistent.
Die Aufgaben sehen wie folgt aus:
Design/Konzept für den folgenden Sprint (Discovery Track)
UX-Beratung des aktuellen Sprints (Delivery Track)
Analyse und Evaluation des vergangenen Sprints (Discovery Track)
Um diese Staffelung klarer zu machen, bietet die folgenden Grafik einen besseren Einblick über die Rolle von UX in den verschiedenen Gleisen.
Design Spikes
Dieser Workflow funktioniert gut im Tagesgeschäft. Aber es gibt Momente, in denen man sich mit unsicheren UX-Herausforderungen konfrontiert sieht, die man nur schwer im Rahmen eines Sprints bearbeiten kann. Der Grund ist, dass das Resultat eines Sprints immer „guter Code“, oder im UX-Fall ein „gutes UX-Konzept“ sein sollte. Was ist aber, wenn man einfach etwas Zeit benötigt, um etwas herauszufinden? Oder eine neue Methode ausprobieren möchte, ohne sich auf ein gutes Resultat aus dieser festlegen zu können? In der agilen Entwicklung gibt es einen Begriff für diese „schnellen Aufgaben“, die einen Lösungen ausprobieren lassen, ohne sich Gedanken um die Resultate machen zu müssen und deren Erarbeitetes dann mit gutem Gewissen weggeworfen werden kann, um mit Vertrauen weiter nach vorn gehen zu können: einen Spike.
Wir nutzen für uns hier genau das Gleiche. Wann auch immer wir Zeit benötigen, um etwas zu erforschen oder „herumzuspielen“, planen wir einen Spike in unsere Sprints ein. Dieser hat dabei eine definierte Timebox und ein definiertes Ziel. Dies kann zum Beispiel etwas sein wie „Herausfinden, ob Empathy Mapping uns dabei helfen kann, die Nutzer besser zu verstehen“. Das Ergebnis des Spikes ist dann nicht zwingend eine großartige Empathy Map, sondern das Wissen, ob wir in Zukunft Empathy Maps für uns nutzen möchten oder nicht.
Fazit
Es ist ziemlich kompliziert, den richten Workflow zu finden, um UX sinnvoll in den Scrum-Prozess zu integrieren. Alle beschriebenen Workflows und Techniken zeigen sicherlich nur einen Teil der Optionen, die man hat, wenn man UX in den Scrum-Prozess integrieren möchte. Es zeigt den Weg, der für uns bisher gut funktioniert: Dual Track Agile mit gestaffelten Sprints und Design Spikes. Wir werden sehen, wie sich dieser Workflow in Zukunft ändern wird, wenn wir neue Erkenntnisse und/oder Know-How haben oder neue Methoden am Horizont erscheinen.
Im Original veröffentlicht auf UX and the City.