UX-Reifegrad-Modell: Eine Anleitung zur Entwicklung von UX-Fähigkeiten in Scrum Teams 

Im 15. State of Agile Report berichten nur 23 % der Befragten, dass sie Lean-UX-Praktiken in agilen Teams anwenden. 

Die geringe Integration von UX-Praktiken in die Arbeitsweise von Scrum Teams ist für mich ein Anzeichen dafür, dass noch viele Scrum Teams einen niedrigen UX-Reifegrad besitzen. Reife Scrum Teams zeichnen sich dadurch aus, dass sie sich aus dem Stadium herausentwickelt haben, in welchem die UX-Aktivitäten von einer einzelnen Person übernommen werden. Bei diesen Scrum Teams konnte ich beobachten, dass dort UX eine Fähigkeit ist, die alle Mitglieder im Team beherrschen. 

Im Folgenden findest du die einzelnen Stadien, die Scrum Teams üblicherweise durchlaufen, wenn sie UX-Aktivitäten in ihre Arbeitsweise integrieren, auf welche Probleme sie dabei treffen und konkrete Handlungsempfehlungen, wie sie ihre UX-Fähigkeiten weiter ausbauen können.

Welche Vorteile können Unternehmen erwarten, die Scrum und UX in Teams vereinen?

Im Jahr 2022 bestimmt die Gestaltung von Produkten und Dienstleistungen die Wettbewerbsfähigkeit eines Unternehmens maßgeblich. 

Beweise dafür gibt es am Markt zuhauf: Als Design-Trendsetter im Smart-Home-Bereich gilt hierfür das Thermostat von Nest. Als Nest 2011 sein Thermostat vorstellte, sahen die meisten Smart-Home-Geräte noch uninspiriert und langweilig aus. „Die Lücke zwischen den Erfahrungen, die Nutzer von mobilen Produkten und den Produkten in unseren Haushalten hatten, war enorm“, schreiben Matt Rogers und Tony Fadell im Nest-Firmenblog. Als ehemalige Apple-Mitarbeiter gründeten sie Nest, um das zu ändern. Ihr Ansatz: 

Design hat oberste Priorität. 

Der Erfolg gibt ihnen recht. Bis heute hat Nest über 11 Millionen Smart-Thermostate verkauft und damit eine Designrevolution im Smart-Home-Bereich entfacht, welche sich auch in vielen anderen Branchen fortsetzt. Denn es reicht nicht mehr aus, ein rein funktionales Gerät zu entwickeln. 

Sollen Produkte die Nutzer begeistern, dann müssen sie auch gut aussehen und dem Nutzer eine positive Erfahrung bescheren. 

Auch wenn es offensichtlich ist, dass besser gestaltete Produkte und Dienstleistungen den Erfolg eines Unternehmens bestimmen, ist es schwierig, diese Einsicht Führungskräften glaubhaft zu vermitteln. Aus meiner Erfahrung ist es Erfolg versprechender, über die Frustrationen zu sprechen, die durch schlechte Nutzererfahrungen verursacht werden:

• Vertriebsmitarbeiter sind frustriert, wenn sie ein Produkt verkaufen sollen, das schwer vorzuführen oder zu erklären ist.
• Die Callcenter-Mitarbeiter sind frustriert durch die vielen Support-Anfragen, die auf ein unverständlich zu bedienendes Produkt zurückgehen.
• Teamleiter sind frustriert, wenn sie die Effizienzverluste ihrer Mitarbeiter verantworten müssen, die auf schlecht designte interne Abläufe zurückzuführen sind. 
• Product Owner sind frustriert, wenn sie erfahren, dass die entwickelten Features ihres Produkts nie genutzt werden. 

Insbesondere zeigen sich die erwarteten Vorteile einer verbesserten Nutzererfahrung, wenn wir die daraus entstehenden Kosten beziffern können. Ich nenne sie die Frustrationskosten. Diese Kosten entstehen durch:

• entgangene Verkaufserlöse
• erhöhte Support-Kosten 
• Produktivitätsverluste
• ungenutzte Features

Nachdem die Vorteile auf der Hand liegen, wenn Scrum Teams auch UX-Fähigkeiten besitzen, stelle ich nun ein Modell vor, wie die Entwicklung dieser Fähigkeiten ablaufen kann.

Wie kann ein UX-Reifegrad-Modell aussehen?

Beim UX-Reifegrad-Modell für Scrum Teams handelt es sich um ein situatives Reifegradmodell. Es hilft also einem Team, die aktuelle Situation zu bestimmen und passende Verbesserungen abzuleiten. 

Ja, wir machen Scrum und die UX-Arbeit wird erledigt durch

• Level 0: Scrum ohne UX
• Level 1: separates UX-Team 
• Level 2: UX-Experten im Team
• Level 3: Zusammenarbeit im Team
• Level 4: jeden im Team

Wie sehen die Level im Detail aus?

Level 0: Scrum ohne UX

Das Scrum Team konzentriert sich uneingeschränkt auf die Erfüllung der geschäftlichen und technologischen Herausforderungen, ohne dabei die Erfahrung der Nutzer zu berücksichtigen. Das offensichtliche Problem, welches hierbei entsteht, lautet: Nutzer, die das Produkt verwenden wollen, müssen selbst herausfinden, wie sie es bedienen sollen. Wenn sie das nicht schaffen, sind sie frustriert und werden das Produkt oder den Service nicht mehr verwenden.

Wir können dieser Situation, welche ich auch als Feature-Factory betitele, entkommen, indem wir

• das Scrum Team sanft an UX heranführen. Das Team muss sehen, dass es Nutzer gibt, die das, was sie entwickeln, tatsächlich nutzen. Deshalb lautet die oberste Prämisse, das Scrum Team mit echten Nutzern in Kontakt zu bringen. Wenn sie sehen, wie Benutzer mit ihrem Design interagieren, wird ihnen klar, dass ihre „Design-Entscheidungen“ Konsequenzen haben. 
• ihnen gegenüber nicht als „Design-Polizei“ auftreten. Am besten ist es, den Teammitgliedern zu verdeutlichen, dass sie Designentscheidungen treffen, ungeachtet der Tatsache, ob sie UX-Experten im Team haben oder nicht.
• einen Fürsprecher für UX im Unternehmen finden. Jemanden, den die Kosten durch eine schlechte Nutzbarkeit der Produkte und Services frustriert und der den Einfluss hat, etwas daran zu ändern. Häufig gelingt es, diese Person als Fürsprecher für UX im Unternehmen aufzubauen, wenn wir ihm die Frustrationskosten vor Augen führen.

Level 1: Es gibt ein separates UX-Team

Diese Phase beginnt, sobald eine Organisation in die Schaffung eines zentralen internen Designteams investiert hat. Dieses Team stellt dann UX-Design-Ressourcen für die Produkt- und Serviceteams bereit. Design-Ressourcen reichen von User-Research über Wireframes bis hin zu UX-Designern. Dabei ergeben sich langfristig drei Probleme:

• Die zentralen UX-Teams ergründen nicht kontinuierlich mit dem Scrum Team die aktuellen Probleme, welche die Nutzer durch ein schlechtes Produktdesign haben, sondern sehen sich nur in der Verantwortung, ein UI-Design zu liefern, damit die Entwicklung nicht stillsteht. Die Zusammenarbeit zwischen UX-Team und Scrum Team gleicht noch einem wasserfallartigen Vorgehen.
• Die zentralen UX-Teams haben immer nur begrenzte Ressourcen. Das Scrum Team muss ihre Verfügbarkeit in der Priorisierung ihrer Arbeit stets berücksichtigen. Diese Abhängigkeit führt zu Verzögerungen und erschwert es dem Product Owner, den Wert der Arbeit der Entwickler wirklich zu maximieren.
• Die separaten Backlogs der Teams reduzieren die Transparenz. Dadurch ist nicht mehr ersichtlich, was das Wichtigste ist, woran die Teams arbeiten sollen, um die Ziele des Produkts oder des Unternehmens zu erreichen.

Folgende Schritte können Scrum Teams auf diesem Level helfen:

• Die Experten des zentralen UX-Teams frühzeitig und langfristig in die Arbeit des Scrum Teams einbinden. Etwa indem wir sie einladen, regelmäßig am Produkt Backlog Refinement und Sprint Review teilzunehmen. 
• Absprache fester Zeiten zur Zusammenarbeit zwischen Scrum Team und Designer. Diese Absprache regelmäßig überprüfen und nach Verbesserungen Ausschau halten. Zum Beispiel durch teamübergreifende Retrospektiven. 
• Die Zusammenarbeit zwischen Designer und Scrum Team so strukturieren, dass ein Bewusstsein für iterative und inkrementelle UX-Arbeit entsteht. Die Einführung von Lean-UX fördert dieses Bewusstsein. Ein konkreter Startpunkt sollte sein, die Entdeckungsarbeit des Scrum Teams mit dem Lean-UX-Canvas zu gestalten.

Es ist ein wichtiger Meilenstein in dieser Phase, in der die UX-Teams noch separate Teams sind, wenn das Scrum Team mit dem zentralisierten UX-Team zunehmend frustriert ist. Wenn das Scrum Team das Gefühl hat, nicht genügend Design-Ressourcen zu erhalten, fängt es nach meiner Erfahrung an, nach eigenen UX-Experten zu fragen. An diesem Punkt ist das Team bereit für das nächste Level.

Level 2: UX-Experten sind Mitglieder im Team

UX-Experten sind jetzt feste Mitglieder im Scrum Team. Dies bedeutet auch, dass sie für die Arbeiten in anderen Teams oder an anderen Produkten oder Dienstleistungen nicht mehr zur Verfügung stehen.

Die zwei großen Herausforderungen dieser Phase:

• Die UX-Experten müssen weiterhin im Austausch mit dem zentralen UX-Team stehen. Das zentrale Team wird in den seltensten Fällen aufgelöst, da es häufig noch andere Scrum Teams gibt, welche noch auf Stufe 1 des UX-Reifegradmodells stehen und weiterhin auf den Service des zentralen UX-Teams angewiesen sind. Das bedeutet aber auch, dass weiterhin weitreichende Designentscheidungen im zentralen Design-Team getroffen werden. Daran sollten die UX-Experten des Teams weiterhin partizipieren, damit eine übergeordnete UX-Strategie einfach gewahrt bleibt.
• Die UX-Experten sind zwar jetzt Teil des Scrum Teams, aber die Arbeit im Product Backlog ist noch klar abgegrenzt. Es gibt Einträge im Product-Backlog für Design und Entwicklung. Designarbeit hat also immer noch einen gesonderten Stellenwert im Scrum Team etwa gegenüber Entwicklungs- und Testaktivitäten.

Die Handlungsempfehlungen, um die Herausforderungen in Level 2 zu meistern, lauten:

• Um den Kontakt zwischen dem zentralen UX-Team und den UX-Experten aufrecht zu halten, hilft es, die Mitglieder des zentralen Teams zu den Sprint Reviews oder Refinements des Scrum Teams einzuladen. Langfristig sollte eine Community of Practice für UX-Design gegründet werden. Diese ermöglicht weiterhin, den fachlichen Austausch zwischen den Teams zu fördern, auch über die Existenz eines zentralen UX-Teams hinaus. 
• Die Intensivierung der Arbeit mit dem Lean-UX-Canvas hilft dem gesamten Team, die Lean-UX-Prinzipien als Grundlage für die Teamarbeit zu etablieren.
• Um den Erfolg der Arbeit des Scrum Teams am Outcome für die Nutzer festzumachen, sollte sich das Scrum Team nun auch outcomefokussierte Sprint- und Produkt-Ziele setzen. Outcomefokussierte Roadmaps helfen, den Nutzer ins Zentrum der Arbeit des Teams zu rücken.
• Der UX-Experte hilft den weiteren Mitgliedern des Scrum Teams erste Entdeckungs-, Design- und Validierungsarbeiten eigenverantwortlich zu übernehmen.

Level 3: Designarbeit wird gemeinsam als Team erledigt

Durch die enge Zusammenarbeit zwischen dem UX-Experten und den anderen Mitgliedern im Scrum Team werden die UX-Fähigkeiten, das Fachwissen und die Erfahrung schrittweise dem ganzen Team zugänglich gemacht.

Grundlegendes UX-Design ist eine erlernbare Fähigkeit. Entwickler, Product Owner und Scrum Master können lernen. Wenn sie viel Zeit mit den UX-Experten in ihrem Team verbringen, lernen sie Schritt für Schritt die Grundlagen. Vielleicht werden sie mit der Zeit dann selbst zu Designern oder sie denken zumindest irgendwann wie Designer. Es gibt nur eine Hürde:

Ja, UX-Design ist eine Fähigkeit, aber auch diese muss erlernt werden!

Hilfreich dabei kann es sein, dass

• der UX-Experte zunehmend als Mentor bei der Ausführung von Design-Aktivitäten durch die anderen Teammitglieder fungiert. 
• sowohl die Definition of Done als auch die Product-Backlog-Einträge so gestaltet werden, dass sie Design-Aktivitäten sowie Entwicklungs- und Testaktivitäten enthalten.
• das Scrum Team emergentes UX praktiziert, es also Entdeckungs- und Lieferarbeit situativ priorisiert. 

Level 4: Jeder im Team designt

Wenn die UX-Experten nicht mehr jede Designentscheidung genehmigen müssen, die Designer nicht mehr jedes Designdetail genau festlegen müssen, wenn es unmöglich wird zwischen Entdeckungs-, Design-, Liefer- und Validierungsarbeiten im Backlog zu unterscheiden, dann sind die besten Voraussetzungen geschaffen, damit das Produkt nicht mehr nur funktional ist, sondern durch sein Design die Nutzer begeistert.

Das Scrum Team ist an dem Punkt angekommen, an welchem gutes Design entsteht, unabhängig davon, wer die Entscheidungen trifft. 

War der Beitrag für dich hilfreich? wenn du Fragen zum UX-Reifegrad-Modell hast, dann melde dich doch zu meiner „Ask a Professional Scrum Trainer German Edition - Scrum + UX” an.