UX in agilen Teams – Probleme und praktische Lösungen

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?

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.

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.

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 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

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!