4 Wege, wie UX-Professionals mit Scrum Teams zusammenarbeiten können
Jedes Scrum Team sollte einen UX-Experten besitzen.
Leider ist das Wunschdenken und entspricht selten der Realität von UX-Professionals und Scrum Teams. UX-Experten, die mein Professional Scrum mit UX-Training besuchen, berichten, dass sie teilweise mit 3 Scrum Teams zusammenarbeiten. Würden sie an allen Scrum Events teilnehmen, dann bliebe keine Zeit mehr, um ihrer UX-Arbeit nachzukommen. Damit haben sie zweifellos recht.
Mitglieder in Scrum Teams verbringen bis zu 22,5 % ihrer Arbeitszeit in den Scrum Events.
Wie komme ich auf diese Zahl? Ein vierwöchiger Sprint umfasst 160 Arbeitsstunden. Dazu zählen das Sprint Planning von 8 Stunden, Daily Scrums von täglich 15 Minuten, das Sprint Review von 4 Stunden und die Sprint Retrospektive von 3 Stunden. Zusammengerechnet sind das 20 Stunden. Setzen wir noch 16 Stunden Product Backlog Refinement an, dann verbringt ein Teammitglied bis zu 22,5 % der Arbeitszeit mit den Scrum Events. Natürlich ist diese Arbeitszeit in keiner Weise unproduktiv oder Verschwendung. Jedoch sind die Scrum Events normalerweise nicht die Zeit, in der Designs erstellt, Komponenten für Design-Bibliotheken entwickelt, Top-Task-Analysen und Tree-Testing mit Nutzern durchgeführt, Anwenderinterviews und Nutzerumfragen unternommen oder User Experience Tests gemacht werden. Wenn ein UX-Experte Teammitglied in 3 Scrum Teams ist, blieben ihm für all diese Tätigkeiten nur mehr 32,5 % seiner Zeit.
Ein Ausweg für viele Scrum Teams besteht darin, die UX-Professionals von allen Teamaktivitäten zu entbinden.
Sollen User Storys entwickelt werden, die ein Design benötigen, werden diese in Jira markiert. So kann der Designer vorab einen Designentwurf erstellen. Erst wenn der Entwurf fertiggestellt ist, ziehen die Coder dieses Ticket im Planning-Meeting. Im Sprint programmieren die Softwareentwickler die nötige Funktionalität. Wenn die Lösung der Designvorlage entspricht, gibt der Designer das Feature im Anschluss frei. Dies geschieht, indem er das Ticket in die „Done“-Spalte verschiebt.
Auf den ersten Blick mag dieses Vorgehen effizient wirken.
Die Teams planen langfristig, wann sie mit dem Designer arbeiten. Der Designer kann seine Arbeiten eigenständig priorisieren. Die Anzahl der Meetings zwischen Softwareentwicklern und Designer sind auf das Wesentliche beschränkt. Allerdings, wenn wir genauer hinsehen, sehen wir einen wasserfallartigen Prozess. Dieser Prozess hat sichtlich nicht zum Ziel, die Arbeitszeit dort zu investieren, wo der größte Mehrwert für den Nutzer zu erwarten ist. Der Prozess unterstützt in keiner Weise, dass Experten aus unterschiedlichen Bereichen gemeinsam die Problemstellung ergründen, welcher der Nutzer gegenübersteht. Diese Arbeitsweise hilft nicht dabei, dass die beste Kombination aus Design, Code, Werbetext und Support gefunden wird. Ein solches Vorgehen unterstützt nicht dabei, zu validieren, ob die tatsächliche Lösung die Nutzer begeistert oder noch verbessert werden sollte.
Wie können Unternehmen dieser Effizienz-Misere entkommen?
Die beste Lösung ist, weitere UX-Professionals einzustellen. Mindestens einen pro Scrum Team. Der Scrum Guide deutet bereits auf die Notwendigkeit hin. Der Guide hält fest: „Das Scrum Team ist umsetzungsverantwortlich für alle produktbezogenen Aktivitäten: Zusammenarbeit mit den Stakeholdern, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte.“
Sollte das kurzfristig nicht möglich sein, dann finden UX Professionals hier 4 Wege, wie sie mit Scrum Teams zusammenarbeiten können. Alle Wege haben ein Ziel: Den Wert, der durch die Zusammenarbeit von dir und dem Scrum Team entsteht, für den Anwender zu maximieren.
Weg #1: Arbeite mit dem Product Owner zusammen
Product Owner müssen die langfristige Perspektive des Produkts mit der kurzfristigen Arbeit bei der Entwicklung vereinen.
Damit alle Arbeiten, die bei der Produktentwicklung anfallen, diese langfristige Perspektive und strategische Ausrichtung widerspiegeln, fokussieren sich Product Owner auf Wert. Dies stellt viele Product Owner vor Herausforderungen: Was bedeutet „Wert“ für das Produkt? Woran erkennen wir, dass wir erfolgreich waren? Für wen schaffen wir Mehrwert? Welche Aktivitäten tragen zur Wertschöpfung bei? Das sind nur einige der Fragen, bei deren Beantwortung Product Owner Unterstützung benötigen.
UX-Professionals können Product Owner unterstützen, indem sie
- User Research durchführen, um mehr über die allgemeine Problemstellung zu lernen,
- Kundeninterviews durchführen, um mehr über die Nutzer zu erfahren,
- gewünschte Ergebnisse für den Nutzer identifizieren,
- Metriken definieren, die diese Ergebnisse messbar machen,
- gewünschte Ergebnisse in Personas festhalten,
- Story-Maps erstellen, um die Interaktion der Nutzer mit dem Produkt, welche zum gewünschten Ergebnis führen soll, darzulegen, und
- Nutzerfeedback auswerten, um neue Ideen zu generieren.
Dabei ist bei all diesen Tätigkeiten wichtig, dass du sie zusammen mit dem Product Owner unternimmst. Das langfristige Ziel sollte es sein, dass der Product Owner ein tiefes Verständnis für den Wert des Produkts entwickelt. Dieses Verständnis ist nötig, damit das Product Backlog nach erwartetem Mehrwert geordnet werden kann. Überdies soll die intensive Zusammenarbeit dazu dienen, dass der Product Owner in Zukunft einige diese Aktivitäten eigenständig unternimmt. Werden etwa Kundeninterviews auch ohne deine Anwesenheit durchgeführt, wird dich dies langfristig entlasten.
Wenn Product Owner verstehen, dass ihr Verständnis über die Nutzung des Produkts entscheidend ist um Wert zu definieren, hebt dies die Notwendigkeit von UX-Experten im Scrum Team noch einmal hervor.
Weg #2: Unterstütze das Scrum Team beim Product Backlog Refinement
Das Product Backlog Refinement ist die andauernde Lernreise, die Ideen zu identifizieren, die so viel Wert für die Nutzer versprechen, dass die umgesetzt werden sollten.
Begreifen Unternehmen ihre Produkte als Lernlabore, dann ändert dies für Scrum Teams alles. Einerseits liefern alle Daten, die das Produkt über das Verhalten der Nutzer sammelt, dem Scrum Team neue Ideen, was sie als nächstes entwickeln können. Andererseits können sie nicht alle Ideen weiterverfolgen. Dieses Dilemma lösen Scrum Teams im Product Backlog Refinement. Im Product Backlog Refinement identifizieren Scrum Teams die Ideen, die am meisten Wert stiften könnten.
Dabei können UX-Professionals das Scrum Team unterstützen, indem sie
- Umfragen, Web-Analysen und Analytik-Daten auswerten,
- Design-Thinking-Workshops anleiten,
- UX-Experimente, wie etwa das Wizard-of-Oz-Experiment, durchführen,
- mögliche User Interfaces mittels Wireframes, Design-Konzepten und Mock-ups visualisieren und
- Anforderungen mit Prototypen und Usability-Analysen vorab validieren.
Je besser das Scrum Team versteht, welche Ideen sich wirklich in Mehrwert für den Kunden verwandeln lassen, desto besser kann die Arbeitszeit der Entwickler und der UX-Experten gewinnbringend investiert werden. Somit ist das Product Backlog Refinement ein Hebel, um den Return-on-Invest zu steigern.
Überdies hilft das Product Backlog Refinement, welches Product Owner, Entwickler und UX-Experten gemeinsam durchführen, den Scrum Teams, das Risiko zu minimieren. Nur wenn Experten aus allen Disziplinen zusammenkommen, können die Verwendbarkeit, die Machbarkeit, der Wert und die Rentabilität effizient bewertet werden.
Product Backlog Refinement ist somit nicht nur eine andauernde Lernreise, sondern dient auch der Risikominimierung. Allerdings nur, wenn Scrum Team und UX-Professionals dabei zusammenarbeiten!
Weg #3: Hilf dem Scrum Team UX-Fähigkeiten zu erlernen
Erfolgreiche Scrum Teams verwandeln das Product Backlog in ein Porträt, wie der Benutzer mit dem Produkt interagieren wird.
Product Backlog Refinement als Tätigkeit sollte als andauernde Entdeckungsreise des Scrum Teams gesehen werden, was für den Nutzer wertvoll sein könnte. Das Product Backlog, welches dabei verfeinert wird, sollten Scrum Teams als eine Momentaufnahme davon sehen, wie der Anwender mit dem Produkt in Zukunft interagieren wird. Diese Sichtweise ermöglicht Scrum Teams, den Wert ihrer Arbeit immer vollständig im Blick zu haben.
Leider ist das nicht die Realität vieler Scrum Teams.
Für viele Teams stellt der Product Backlog nur eine Liste zusammenhangsloser Anforderungen von unterschiedlichen Seiten an das Produkt dar. Um das zu ändern, braucht es dich als Experten für die Nutzung des Produkts. Als UX-Experte kannst du jeden Entwickler im Scrum Team dabei unterstützen, diese Haltung einzunehmen: Alles, was Produktentwicklungsteams tun, sollte den Nutzern des Produkts eine bessere Zukunft ermöglichen, ihr Leben vereinfachen oder erleichtern. Dazu müssen sich die Anwender allerdings tagtäglich in die Nutzer ihres Produkts hineinversetzen.
Bitte verstehe mich nicht falsch. User Experience ist eine Profession, die viele Facetten hat und Fähigkeiten benötigt. Es wäre realitätsfern zu behaupten, dass jeder Entwickler das können muss und erlernen kann. Es geht mir hier darum, dass Entwickler ein gewisses Grundverständnis erlangen sollten. Du als UX-Experte, dessen Verfügbarkeit der Flaschenhals ist, kannst dem Team helfen, dieses Verständnis zu erlangen. Aber nur wenn du sie dazu anleitest und nicht, wenn du alle Arbeiten eigenständig für sie erledigst.
Hilft den Entwicklern
- Fähigkeiten im Story-Mapping oder Customer-Journey-Mapping zu erlangen,
- in Ergebnissen für die Nutzer zu denken,
- Kundeninterviews durchzuführen,
- zu verstehen, wie sie Style- und Branding-Richtlinien folgen können,
- zu lernen, wie sie die Anwendungen auf Barrierefreiheit testen können und
- zu verstehen, was die grundlegenden Designprinzipien sind, welchen deine Designentwürfe folgen.
Letztlich sollten UX-Experten auch Teil eines Scrum Teams sein. Solange das noch nicht der Fall ist, solltest du den Menschen im Team helfen, sich weiterzuentwickeln und einige deiner Fähigkeiten zu erlernen. Nur so lässt sich das Flaschenhalsproblem langfristig etwas lindern.
Weg #4: Unterstütze das Scrum Team bei der Validierung der Produktqualität
Wer bestimmt, ob die Qualität des Produkts ausreichend ist?
Am Ende ist es immer der Kunde mit seiner Kaufentscheidung! Um bei der Auslieferung eines Produkts oder einer neuen Version keine böse Überraschung zu erleben, sollten Unternehmen gewisse Qualitätsstandards vorgeben. Wie Scrum Teams diese Standards sicherstellen wollen, halten sie in der Definition of Done fest. Da der Nutzer des Produkts schlussendlich entscheidet, ob die Qualität ausreichend ist, sollten diese Standards auch Nutzbarkeitskriterien enthalten.
Du kannst das Scrum Team dabei unterstützen, Kriterien zu finden, die die Verwendbarkeit des Produkts beschreiben. Hier einige Beispiele, die Teil der Definition of Done sein könnten:
- hält sich an den aktuellen Styleguide
- hält sich an das Design-System
- wurde auf Barrierefreiheit getestet
- die Nutzungsmetriken sind definiert
- es wurde definiert, wie Kundenfeedback gesammelt wird
- Anwendertests wurden durchgeführt
Neben der Definition, welche Tätigkeiten das Scrum Team unternehmen soll, um die Qualität des Produkts sicherzustellen, kannst du helfen, dass das Team diese auch erfüllt.
Eine effektive Möglichkeit bietet hier das Pairing. Verabrede dich dazu mit einem Entwickler des Teams. Dann führt ihr die Tests auf Funktionalität, Nutzbarkeit, Barrierefreiheit und so weiter gemeinsam durch. Kurzfristig sehen vier Augen mehr als zwei und langfristig lernt der Entwickler, wie er die Produktqualität aus Sicht der Verwendbarkeit validieren kann.
Da die Qualität der Produkte für die Qualität der Arbeit des Unternehmens steht, sollte die Sicherstellung dieser niemals an Teamgrenzen scheitern.
Working-Agreement: Wege der Zusammenarbeit transparent machen
Mit dem Product Owner eng zusammenzuarbeiten, das Scrum Team im Product Backlog Refinement zu unterstützen, den Teammitgliedern grundlegende UX-Fähigkeiten vermitteln und das Team zu unterstützen, die Produktqualität zu überprüfen, sind alles hilfreiche Wege, wie UX-Experten die Scrum Teams, mit denen sie zusammenarbeiten, unterstützen können.
Alle diese Wege vereint, dass sie disziplinübergreifende Zusammenarbeit ermöglichen und dazu beitragen, langfristig UX-Fähigkeiten im Team zu entwickeln.
Die Frage, die jetzt noch offenbleibt: Womit sollte die Zusammenarbeit beginnen?
Scrum Teams managen ihre Arbeit selbst. Diese Selbstmanagementfähigkeit ist entscheidend für den Erfolg von Scrum Teams. Nur so sind sie in der Lage, bei Veränderungen in ihrem Umfeld ihre Arbeitsweise entsprechend anzupassen. Den Rahmen, innerhalb dessen das Selbstmanagement stattfindet, definieren die Elemente des Scrum Rahmenwerks. Damit diese Fähigkeit erhalten bleibt, müssen die Rahmenbedingungen auch in der Zusammenarbeit mit dem UX-Professional abgesteckt werden.
Ein gutes Werkzeug hierfür ist ein Working-Agreement. Indem es die Erwartung aller festhält, macht es die Zusammenarbeit transparent. Transparenz bildet die Grundlage für Anpassung und Verbesserung.
Hier findest du vier Leitfragen und etwaige Antworten, um ein sehr leichtgewichtiges Working-Agreement aufzusetzen:
Warum arbeiten wir zusammen?
Wir möchten den Wert unseres Produkts für unsere Nutzer maximieren, indem wir ihre funktionellen und visuellen Erwartungen übertreffen.
Was erwarten wir voneinander?
- Zusammenarbeit und Entwicklung von UX-Fähigkeiten
- UX-Professional priorisiert seine Zeit so, dass Zeit bleibt, mit Product Owner zu arbeiten und am Produkt Backlog Refinement teilzunehmen
- UX-Professional erstellt visuelle und funktionelle Richtlinien für Product-Backlog-Einträge, die dann im Refinement gemeinsam weiter ausgearbeitet werden
- Scrum Team geht aktiv auf UX-Professional zu, wenn es Unklarheiten bei der Entwicklung von Product-Backlog-Einträgen gibt
- Scrum Team testet Product-Backlog-Einträge zusammen mit UX-Professional
Wann können wir es erwarten?
- UX-Professional ist jeden Tag während der UX-Working-Hour erreichbar
- Aufgaben, die UX-Arbeiten erfordern, werden mit dem Tag „UX“ gekennzeichnet
- Scrum Team lädt UX-Professional aktiv zu den Scrum Events und dem Product Backlog Refinement ein, wenn es erforderlich ist
Wann überprüfen wir unsere Zusammenarbeit spätestens wieder?
- Sprint Retrospektive am Ende jeden Quartals