UX in agilen Teams – Probleme und praktische Lösungen
- Autor Björn Frieling
- Kategorien Agile
- Date 11. November 2019
Die Disziplin UX ist für viele Unternehmen neu. Gerade in der Zeit der digitalen Transformation setzen immer mehr Unternehmen bei der Entwicklung auf agile Methoden. Aber wie verhält sich UX in agilen Teams und wie lässt sich UX mit agiler Entwicklung vereinbaren?
Im Folgenden möchte ich einen Lösungsansatz skizzieren, wie dieser auch von der Nielsen Norman Group in großen Teilen gelehrt wird (siehe hier). Aber auch meine eigene Erfahrung aus nun 4 Jahren SCRUM und UX erläutern.
Problematik von UX in agilen Teams
Als SCRUM ‚erdacht‘ wurde, hat die Disziplin UX so wie heute noch nicht existiert. Daher ist UX keine ‚Kerndisziplin‘ wie zum Beispiel die Rolle des Entwicklers. Viele SCRUM Prozesse sind ähnlich zum User Centered Design Prozess. Ein häufiges Problem ist, dass SCRUM nicht vorsieht, dass eine Disziplin innerhalb eines Teams außerhalb des Sprint Backlogs arbeitet. In der idealistischen Theorie arbeitet jeder im Team unmittelbar am Produkt und an den gleichen Stories. Falls jemand ausfallen sollte, kann ein anderer übernehmen.
Kommunikation und externe Abhängigkeiten
Das Problem von UX in agilen Teams ist oft lediglich ein Kommunikatives. Der UCD unterscheidet sich durch seine Iterationen nicht wirklich vom agilen Mindsets. Was allerdings unterschiedlich ist, dass UX eine gewisse Vorlaufzeit vor einem Sprint benötigt.
Du kannst UX in agilen Teams sehr wertvoll gestalten. Die Entwickler wollen bevor sie starten wissen, wie eine Anwendung ablaufen soll. Daher ist die Kommunikation zwischen UX und Entwickler sehr wichtig. Auch willst du nicht immer etwas konzipieren und es 2 Wochen später wieder komplett wegwerfen.
UX ist daher notwendig, um sehr gute User Stories zu schreiben. Aber als Teil der Story und der Akzeptanzkriterien. UX ist nicht ein Teil des Development Teams im engeren Sinne von SCRUM.
Wie lässt sich diese Problematik praktisch lösen?
Zusammenstellung eines agilen SCRUM Teams
Nach SCRUM gibt es in einem Team einen PO (Product Owner) einen SM (Scrum Master) und ein Entwicklungsteam (Dev. Team) (Rollen in SCRUM). Die einzelnen Rollen zum Beispiel Frontend – Entwickler, Backend – Entwickler, Architekt, Tester, Business Analyst, etc. sind nach SCRUM nicht weiter spezifiziert.
In dieses Dev. Team gehört auch ein UX – Professional. Ein Experte, der den Fokus des Teams und des Produkts auf den Kunden und Nutzer richtet. Doch sollte diese Rolle nicht innerhalb der engen Sprint Strukturen arbeiten.
UX in agilen Teams und externe Abhängigkeiten
Was dagegen spricht? Nach dem UCD werden alle Konzepte getestet. Allein dies ist eine externe Abhängigkeit, wie sie in keiner User Story vorzufinden sein sollte. Ein Usability Test erfordert externe Teilnehmer, Räumlichkeiten und Zeit zur Vor- und Nachbereitung. Dies alles in einem Sprint unterzubringen ist schwer, wenn nicht gar unmöglich.
Aber auch ohne das Testen, solltest du die Konzeption in einem vorherigen Sprint machen und nicht während des eigentlichen Sprints. Denn im Gegensatz zu einigem Code, musst du beim Konzept immer die gesamte Funktion betrachten.
Dual Track auf deinem eigenem UX – Board
Eine mögliche Lösung ist es einen Dual – Track Ansatz zu nutzen. Dabei arbeitet der UX – Professional auch in Sprints mit der gleichen Länge wie das Dev. Team. Der Sprint für den UX läuft allerdings 1 – 2 Sprints vor dem des Dev. Teams ab.
Der User Researcher
Dieser Ansatz löst noch nicht die Problematik mit externen Abhängigkeiten bei Usability Tests. Hierfür bietet es sich an, zum Beispiel einen Test Parking Lot zu erstellen. Auf diesem Board sammelt ihr, welche Themen getestet werden müssen.
Eine andere Methode ist möglich, wenn ihr in einem größeren Projekt mit mehreren Teams seid. Dann wäre es ein praktikabler Ansatz, wenn jedes SCRUM – Team einen eigenen UX – Professional hat. Zusätzlich würde es eine übergeordnete Rolle (außerhalb der SCRUM Teams) geben, die sich als User Researcher bezeichnet.
Dieser Researcher macht die User Research für alle Teams und unterstützt dich als Dev. Team Mitglied in deiner Arbeit. Ein Vorteil dieser Methodik ist auch, dass der Researcher einen Überblick über die einzelnen Funktionen erhält, die teilweise teamübergreifend sein können. Diese lassen sich dann besser und ganzheitlicher Testen.
Deine Aufgaben während eines Sprints
Als UX – Professional hast du mehrere unterschiedliche Aufgaben während eines Sprints. In der unteren Abbildung ist gut zu sehen, wie der unterschiedliche Fokus in jedem Sprint aussehen kann und sollte. Je näher eine Aufgabe an der ‚Taschenlampe ist‘ desto höher ist die Priorität.
Support für dein Team und den PO
Die Hauptaufgabe während des Sprints besteht darin, das eigene Team bestmöglich zu unterstützen. Das bedeutet jederzeit ansprechbar für die Entwickler und den PO zu sein. Unklarheiten zu klären und vor Reviews für alle Stories zu machen, welche unmittelbare Relevanz für den Kunden haben.
Auch die Beratung des POs gehört zu deinen Aufgaben als UX - Professional. Dort ist es wichtig immer wieder den Fokus auf den Kunden und Nutzer zu legen. Auch solltest du immer beim Refinement anwesend sein, um Unklarheiten zu beseitigen. Gerade abstraktes Verhalten, welches du nicht in einem adäquaten Prototypen vorbereiten kannst (zum Beispiel alle möglichen Validierungen) kannst du dort deinem Team erklären.
Konzepten und Tests
Die Konzeption für neue Funktionen für den nächsten oder übernächsten Sprint zu erstellen, ist eine weitere deiner Aufgaben. Dabei gilt auch hier, dass du dich fokussierst und die nächsten Funktionen in Absprachen mit deinem PO vorbereitest. Nur durch eine aktive Kommunikation kann UX in agilen Teams funktionieren.
In manchen Sprints wirst du je nach Projektkonstellation auch Zeit haben deine Konzepte zu testen oder eben testen zu lassen. Nutze das oben besprochene Testbacklog, um mögliche Synergien im Testen zu entdecken. Vielleicht ergibt sich die Möglichkeit mehrere Funktionen in einem Usability Test zu testen.
Strategie und weiteres User Requirements Engineering
Wenn du dann in dem Sprint noch Zeit hast, dann kannst du dich daran machen die UX Strategie für dein Team, dein Projekt oder dein Unternehmen weiter zu entwickeln. UX in agilen Teams bedeutet nicht nur eine Fokussierung auf den jetzigen Sprint, sondern auch dem Team immer wieder einen Ausblick auf die Zukunft zu geben.
Auch wenn das User Requirements Engineering laut User Centered Design Prozess ganz am Anfang stattfinden sollte, so kommen doch im Laufe der Zeit immer neue Anforderungen hinzu. Du wirst feststellen, dass in deinen Evaluationen immer weitere Anforderungen und Bedürfnisse der Nutzer herauskommen. Auch kann es sein, dass du neue Nutzungskontexte entdeckst. Diese gilt es dann zu notieren und in dieser Phase zu validieren. Auch ein Blick auf die Abdeckung deines Produkts hinsichtlich dieser Anforderungen.
UX in agilen Teams bedeutet Kommunikation
UX in agilen Teams bedeutet vor allem Kommunikation. Rede mit deinen Stakeholdern, mit den Kunden, deinen POs und vor allem auch deinem Team. Hole alle Anforderungen an dein Produkt ein und kommunizieren schon aber der ersten Gedankenphase, wie du dir das Produkt vorstellen könntest. Welche Lösungen du hast. Und vor allem lass dein Team daran partizipieren.
Erläutere deinem Team die Ideen und wie dieser deiner Meinung nachwirken sollen. Nimm dein Team mit auf Tests und präsentieren Ihnen ganz transparent die Ergebnisse. Dies ist wichtig für die Akzeptanz von UX im Team, im Projekt und im Unternehmen. Nur wenn du genügend kommunizierst, schaffst du es nicht als ‚Pixelschubser‘ angesehen zu werden. Nicht jedem ist die Wichtigkeit von UX von vornherein bewusst, also liegt es dir dein Team von dir und der Disziplin zu überzeugen
Zusammenfassung
Als UX Professional in agilen Teams hast du unterschiedliche Aufgaben. UX ist keine Kerndisziplin in vielen agilen Frameworks mit SCRUM. Entsprechend musst du gegen viele Barrieren kämpfen. Aber es gibt mittlerweile mehr praktikable Lösungen und auch mehr Verständnis. Dennoch gibt es noch immer Konstellationen die UX erschweren. Zum Beispiel, wenn es 1 UX – Professional für 2 Teams gibt. Auch wie UX dann teamübergreifend stattfinden soll ist nicht so einfach. Auch die Konstellation von kleinen UX Teams außerhalb der SCRUM Teams ist nicht unüblich.
Merke dir einfach: UX und SCRUM sind nicht konträr zueinander, sondern gleichen sich sehr stark. Mit einem Dual Track kannst du problemlos in SCRUM arbeiten. Und wie das in agilen Teams üblich ist, versuch es doch einfach mal!
Tag:Agil, Agilität, forhappyusers, Methodik, Prozesse, SCRUM, Strategie, User Experience, UX, UX Lead