Die 5 grössten Mythen von UX und Scrum

Am UX Brunch im September 2016 durften Daniele Gallo und ich der UX-Community über unsere Erlebnisse in einem Scrum-Projekt berichten. UX und Scrum ist ein heisses Thema, die Gemüter schlagen hoch und jede Menge Vorurteile – oder Mythen –, manche stimmen, manche nicht, schlagen auf die Projekte ein. UX hängt hier an vielen Stellen genauso quer in der Landschaft wie Usability-Tests kurz vor dem Go-Live.

Ein Mythos ist ebenso eine Legende, die einem immer wieder begegnet, die sich hält und selbst verteidigt und an die sich selbst dann noch erinnert wird, wenn ein Paradigmenwechsel sie längst widerlegt hat. Das macht den Umgang mit ihnen so anstrengend. Unsere fünf Favoriten sind:

1. Konzipieren kann jeder.
2. UX-Design macht man einmal und fertig.
3. Das Scrum-Vorgehen rettet die Seifenkiste.
4. Ich mache UCD, wenn ich meine Nutzer frage, was sie wollen.
5. Die Produktvision ist mit dem Scope im Wandel.

Konzipieren kann jeder.

Ja und Nein: Konzepte haben viele verschiedene Flughöhen, der Begriff an sich ist weit definiert. Genau das macht es so schwierig, diesem Mythos zu begegnen. Wenn wir in einem Projekt die Fachkompetenz Interaction Design einsetzen, heisst das noch lange nicht, dass klar ist, was das eigentlich ist. Das zeigte sich z.B. so: «Ich hab dir doch alles aufgezeichnet, was dauert da jetzt noch so lange?» Was hilft aus unserer Sicht ist tatsächlich Aufklärung und die gebetsmühlenartige Wiederholung, dass eine Applikation mit und ohne Interaktionskonzept tatsächlich unterschiedlich aussehen wird. Das Bild links kennt ihr sicher, hilft auch.

UX-Design macht man einmal und fertig.

Der Klassiker! Was ist, wenn wir was dazu lernen? Hm, dann ist der UX-Spezialist schon wieder weg. Schade. Dass die Kompetenz immer wieder gebraucht wird, vor allem, wenn wir in kleineren Dosen wie im agilen Vorgehen uns die UX zur Brust nehmen, müssen wir zwar erklären, aber auch zeigen. Leider verstehen es einige unserer Fachkollegen, so viel über UX, UCD, Usability und Co. zu reden, dass sie das Machen vergessen. Evangelist zu sein reicht hier nicht, Tatsachen schaffen und am echten Inkrement (also der entstehenden Applikation) zeigen, was die UX-Massnahmen gebracht haben, überzeugt weit mehr. Hier bietet die agile Vorgehensweise sogar einen Mehrwert: Ich kann viel häufiger zeigen, was warum getan wurde und welchen Effekt es hatte, idealerweise in jedem Review. «Liefere, nöd lafere», sagen meine Schweizer Kollegen.

Das Scrum-Vorgehen rettet die Seifenkiste.

Vom Team selbst abgesehen, ist vom neuen Denkmodell auch die gesamte Organisation betroffen. Entscheidungen im Scrum werden plötzlich anders getroffen, der Weg, den ein Produkt macht, unterliegt dem konsequenten Priorisieren des Product Owners. Gremien und Stakeholder von Scrum-Projekten führen gern Scrum ein, weil sie sich erhoffen, schneller zu sein – und in der Tat, wenn ein Scrum-Team ausreichend Autonomie erhält, wird es schneller. Doch die Geschwindigkeit überfordert die gleichen Gremien und Stakeholder, die eben noch danach gefragt haben. Sie verlangen nach Abstimmung, nach Entscheidungskompetenz über die Backlog-Einträge, sie erwarten Perfektion statt Adaption – im Wasserfall darfst du dich nicht irren in der Anforderungsphase, du darfst nichts vergessen. Wieder entsteht Redebedarf. Daniele und ich werden auch hier nicht müde zu erklären, warum wir welche Schritte unternehmen. Ist eine Organisation gar nicht reif dafür, das Tempo zu antizipieren, bleibt vermutlich erstmal Arbeit auf oberster Ebene zu tun, um den Product Owner zu legitimieren. Nicht in jedem Fall wird Scrum der Heilsbringer sein, insbesondere dann nicht, wenn den Protagonisten die Puste ausgeht.

Ich mache UCD, wenn ich meine Nutzer frage, was sie wollen.

Das Vertrackte ist, dass ich als Fragender vom Befragten tatsächlich eine Antwort erhalte, wenn ich so ähnlich frage: «was willst du im nächsten Release?»… wir erinnern uns kurz an Henry Ford: «Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde.» Mit Daniele bin ich mir einig, dass wir mit dem stärksten aller Fragewörter nachlegen: «Warum?» – es liess sich in der Regel nicht verhindern, dass die Fragen so gestellt werden und die Predigt ständig zu hören, dass man anders fragen muss, ist ja auch nervig. Bei der Abstimmung über Anforderungen «Warum?» zu fragen, ist ziemlich einfach und fördert erstaunliche Erkenntnisse in den Menschen zutage. Wir erfüllen keine Wünsche, das macht der Weihnachtsmann, wir lösen Probleme. Das «Warum» bringt uns näher an das Problem. Haben wir das verstanden, können wir Lösungen anbieten, auf die Nutzer gar nicht kommen können. Kleine Faustregel am Rande: Je mehr Konjunktiv in der Frage steckt, desto weniger zuverlässig ist die Antwort der Befragten.

Die Produktvision ist mit dem Scope im Wandel.

Auch schön, das ist jedoch ein impliziter Mythos, der so nicht verbalisiert wird und damit einer der jüngeren seiner Art. Jeden in unserem Scrum-Team können wir nachts um 4 wecken und er sagt die Produktvision auf, sie hat auch nur einen Satz, der ist aber mächtig. Wenn uns Anforderungen entgegen plätschern, werden sie schlicht niedriger priorisiert, wenn sie der Produktvision entgegenstehen. Oft aber ist das gar nicht möglich, weil die Anforderung, so wie sie uns gestellt wird, die Lösung für ein Problem darstellt, das noch gar nicht richtig verstanden ist. Das heisst für uns wieder den Projektfleischwolf anzuwerfen, der das Problem extrahiert. Meistens können wir dann das Problem tatsächlich lösen, ohne die Produktvision zu verraten. Summa summarum sind wir gern bereit, neue Anforderungen in den Scope zu nehmen, bei der Produktvision sind wir heikler. Wenn der Markt sich weiterbewegt oder Unternehmensziele ändern, kann die Produktvision natürlich auch ändern. Allerdings hat das rechte Konsequenzen auf das betroffene Produkt. Deshalb ist die Produktvision unser höchstes Gut, wir zeigen sie jedem, erklären sie gern und plakatieren damit Wände.

 

Wer so viel über Mythen redet, ist natürlich auch an den Geschichten anderer interessiert. Am UX-Brunch haben wir daher eine kleine Umfrage gemacht, welcher Mythos den UX-Freunden begegnet ist, welcher sich aus ihrer Sicht besonders hartnäckig hält und welchen weiteren sie uns nennen können. Der Gewinner in den beiden ersten Kategorien ist eindeutig «Ich mache UCD, wenn ich meine Nutzer frage, was sie wollen.».

 

Meine persönlichen zusätzlichen Mythos-Favoriten aus der Umfrage:

• UX macht Agile langsamer.
• Man braucht max. 2 Tage für UX.
• UX kostet zu viel Geld.
• Wir wissen was unsere Nutzer wollen.
• Es reicht, wenn ich UX für mein Produkt isoliert anschaue.
• Mehr Features sind besser & dadurch passt eine Lösung für alle Nutzergruppen…
• Scrum macht kulturelle Probleme obsolet.
• UX = Visual Design
• Fragebogenresultate sind die Wahrheit. Egal wie schlecht der Fragebogen und die Erhebungsmethode.
• Marktforschung reicht, ist das gleiche wie UX.
• UX Designer sind die neuen Webdesigner.

… und über jeden gäbe es ein Füllhorn an Geschichten zu erzählen… das UX-Einhorn vermisse ich noch. Auch das: eine unbenannte Legende.