Agiles Arbeiten (Scrum) und nutzerzentriertes Design gehören als Erfolgsfaktoren für gute Software bei slashwhy untrennbar zusammen. Denn UX Design und Scrum haben das gleiche Ziel: Mehrwert schaffen durch gebrauchstaugliche/nutzbare (usable) Produkte. Auch wenn der Scrum Guide keine Aussagen dazu macht, wie UX-Design-Arbeit prozessual mit anderen Aktivitäten (im Sprint) integriert sein sollte, so haben sich über die Jahre Best Practices entwickelt. In diesem Artikel möchten wir für euch zusammenfassen, wie sich unser integriertes Bild von User Experience und agiler Produktentwicklung mit Scrum weiterentwickelt hat.

Transparenz und Offenheit

Am Anfang unserer Reise standen Sorgen und Fragen – Sorgen und Fragen unserer UX Designer, unserer Agile Coaches und auch der Entwickler:innen. In den „Frequently Asked Questions“ eines Scrum Teams standen Dinge wie: Schätzen die Designer und Entwickler:innen die Stories von allen mit? Schreiben wir die Stories in zwei separate Backlogs? Wie lassen sich in der Definition of Done nichtfunktionale Qualitätsmerkmale, verankern? Welche Rolle spielt die UX in einer Produkt Vision? Und der „Evergreen“: Wie lassen sich Design-Evaluation oder -Exploration in Sprints integrieren? Wer votet eigentlich noch für die Action Items der zwei Designer im acht Personen starken Team? Als UX-Designer waren wir damit konfrontiert, unsere Aktivitäten in einen vermeintlich festgelegten Scrum-Prozess abzubilden.

Gemeinsames Experimentieren und Lernen

Unsere Agile Coaches haben das getan, was sie in ihrem Job tun: Zuhören, wo der Schuh drückt und auf Augenhöhe mit allen Beteiligten Lösungen erarbeiten. Das ist ein wichtiger Teil unserer Unternehmenskultur bei slashwhy: wir identifizieren Entwicklungspotenziale und haben die Möglichkeit, uns eigenverantwortlich zu engagieren, um neue Wege zu beschreiten. Zudem hat der Blick nach links und rechts uns gezeigt, dass in anderen Organisationen gut durchdachte Lösungen vorhanden sind und sich dort etabliert haben. Unter anderem lässt sich die Zeit in den Sprints sehr effizient nutzen, indem zeitlich versetzt Aktivitäten von Lernen (Discovery) und Umsetzen (Delivery) stattfinden. Wir brauchten aber einen flexibleren Rahmen, der es ermöglicht, Agilität und Scrum zu leben. Nämlich so, dass das Team immer noch entscheiden kann, wie es im Detail arbeiten möchte.

Unsere Lösung scheint auf den ersten Blick sehr einfach: Der Scrum Prozess bleibt im Grunde so, wie er ist. Das Team muss unbedingt crossfunktional aufgestellt sein und diesen Gedanken zusammen mit PO und Scrum Master auch wirklich leben (lernen). So kann jede:r Beteiligte an bestimmten Punkten bei der Produktentwicklung besonders darauf achten, seinen Beitrag zur nutzerzentrierten Entwicklung zu leisten.

Geteilte Verantwortung für UX durch crossfunktionale Teams

Wie sieht die ideale Zusammenarbeit in einem (Scrum-)Team aus? Die Mitglieder vertrauen einander und fühlen sich sicher in ihrem Team. In diesem Umfeld können sie ihre Ideen und Anmerkungen frei äußern und sich gegenseitig Feedback geben (fachliches wie auch persönliches). Auch "Nicht-Designer" sollten sich an UX-Design-Aktivitäten beteiligen; bspw. im Rahmen von Nutzungstests oder der Entwicklung von Bedienkonzepten. Dies verbessert das gemeinsame Verständnis und den Austausch im Team. Es ist hilfreich die Perspektive der jeweils anderen Rollen im Team einzunehmen z.B. in wechselseitigen Formaten wie dem „Pair Programming / Designing“.

Des Weiteren stellen Menschen außerhalb des Teams Anforderungen an das Projekt und haben berechtigtes Interesse die Entwicklung zu verfolgen. Diese Personen auf dem agilen Weg der Produktentwicklung mitzunehmen, aktiv miteinzubeziehen und zu ermutigen nutzerzentrierter zu denken, ist eine kontinuierliche Herausforderung für unsere crossfunktionalen Teams. Es sollte für Stakeholder nicht nur bei der Teilnahme an UX-Workshops bleiben. Mittels weiterer Aktivitäten, wie der Beobachtung von Nutzerinterviews, der Teilnahme an Sprint Reviews, hat ein crossfunktionales Team Möglichkeiten, Stakeholder in die nutzerzentrierte Entwicklung mit einzubeziehen. So kann es gelingen nicht nur transparent den Projektfortschritt zu kommunizieren, sondern auch in einen stetigen Austausch mit Stakeholdern zu treten.

In einem solchen Team sind User Experience Designer die Spezialist:innen, die wissen, mit welcher Methode Informationen über Nutzer:innen erhoben und konsolidiert werden. Sie wissen, mit welcher Methode die Erkenntnisse mit Team und Stakeholdern geteilt werden sollten, um ein gemeinsames Verständnis zu schaffen. Diese intensive Crossfunktionalität hängt jedoch sehr stark davon ab, wie sie gelebt wird und wie diese Haltung gefördert wird.