Ist das Scrum-Team bereit für UX?

«User Experience und Scrum» ist zurzeit ein Thema vieler Vorträge – kein Wunder, es merken viele Unternehmen, sei es auf Kunden- oder Dienstleistungsseite, dass sie ohne positives Nutzererlebnis auf dem Markt von anderen Mitspielern überholt werden. Zusätzlich wollen sie von einer schnelleren Time to market dank agiler Vorgehensweisen profitieren. Aber ist denn das Scrum-Team überhaupt bereit für UX? Was braucht es, UX im Scrum zu berücksichtigen? Und wann sollte ein Scrum-Projekt auf UX schauen?

UX als Fähigkeit des Scrum-Teams

Nebst den zwei wichtigen Rollen des Scrum Masters und Product Owners besteht ein Scrum-Team aus «Entwicklern». Das Entwicklungsteam, so missverständlich die Bezeichnung so klar der Sinn, besteht aus allen für das Erstellen des Produkts notwendigen Fachkompetenzen. Das macht es einfach: UX gehört ins Entwicklungsteam!

Beim Staffing sollte jeder Product Owner mit dem Scrum Master sehen, die Fähigkeit besetzt zu haben. UX Designer, Usability Engineers, Interaction Designer und viele andere Bezeichnungen können solche Spezialisten tragen, nicht jeder bringt den gleichen Methodenkoffer mit. Und es ist nicht zwingend so, dass dieser Mensch «nur» Wireframes oder Prototypen erstellt. Es kann gut sein, dass er auch Nutzertest durchführen oder ein Frontend mitentwickeln kann. Genauso können auch Backend-Entwickler Frontend-Kenntnisse haben. UX ist also keine Rolle, sondern eine Aufgabe!

Wann sollen UX-Themen eine Rolle spielen? Möglichst früh und im ganzen Prozess, also ab dem Ramp Up, in jedem Sprint und speziell im Refinement! Nutzt die Fähigkeiten und das Methoden-Repertoire des UX-Designers, um das Produkt zu formen – von der Vision über das einzelne Feature bis hin zum fertigen Produkt! Aber sondert ihn nicht ab. Er muss Teil des Teams sein, genauso für die Produktvision einstehen wie die übrigen Entwickler und verstehen, warum was im Produkt landet oder nicht – gemäss der Prioritäten des Product Owners.

An dieser Stelle ein Hinweis an POs und Scrum Masters: bereitet das Scrum-Team auf die Wirkung von Nutzer-Feedback vor. Dafür kann dem Entwicklungsteam die Möglichkeit gegeben werden, Nutzerfeedback mitzuerleben: in Usability-Tests beisitzen oder einmal einen Hallway-Test selbst durchführen wirken wahre Wunder.

Was, wenn nicht?

Gemäss Nielsen’s «The State of UX Agile Development» verwenden etwa ein Viertel der Anwender von agilen Prozessen einen hybriden Ansatz und gehen nicht strikt nach agilen Praktiken. Ein Wasserfall-Vorgehen würde demnach für Anforderungen und Design-Phasen und ein agiles Vorgehen für die spätere Umsetzung verwendet werden. Und ja: das begegnet auch uns in unseren Projekten. Der Schaden ist einfach umrissen: Entwicklungswissen fliesst nicht ins Konzept, Interaktionsdesigns werden für die Halde produziert und ehe ein Feature überhaupt im Backlog an der Reihe wär, muss es sowieso neu konzipiert werden, weil sich das Konzept selbst überholt hat und man (hoffentlich) dazu gelernt hat. Genau dieser Haldenproduktion lässt sich vorbeugen, wenn das Konzept mit agilisiert wird. Das fängt schon damit an, dass Fachspezialisten, Interaktionsspezialisten und Software-Entwickler nicht im Auftraggeber-Auftragnehmer-Verhältnis arbeiten, sondern über ihre Entscheidungskompetenzen hinweg schlicht die beste Lösung suchen.

Kommunikation ist ein wichtiger Punkt und muss im ganzen Scrum-Team gesund passieren. Stellt euch vor, der Entwickler kann oder darf nicht mit dem UX-Designer sprechen, obwohl sie an der gleichen Story arbeiten. Wie soll denn da ein Mehrwert für ein Produkt entstehen? Es ist sehr inspirierend und zielführend, wenn sich zwei Personen ergänzen und zusammen, nebeneinander an der optimalen Lösung tüfteln. Dafür gibt es auch Ausdrücke wie Pair-Design, Pair-Programming und so weiter. Wichtig sind an dieser Stelle nicht die Bezeichnungen, wichtig ist, dass man es tut und dem Team auch die Möglichkeit dazu gegeben wird! Verteilte Teams geht schon, das beste Ergebnis wird es aber mit einem gemeinsamen Team-Raum geben.

Also alles ganz einfach?

Damit das Scrum-Team bereit für UX ist oder wird, braucht es die Voraussetzungen in der Organisation. Denn wenn die Organisation kein Scrum zulässt, wird es unmöglich sein, ein Produkt agil zu entwickeln, geschweige denn UX zu integrieren. Meine Ausgangsfrage, ob das Scrum-Team bereit für UX ist, kann ich mit «Ja» beantworten, wenn «bereit» wirklich bedeutet, dass alle verstanden haben oder verstehen wollen, wie in einem Scrum-Team gearbeitet wird.
Hier nochmals die wichtigsten Voraussetzungen, wie UX im Scrum-Team zum Erfolg werden kann:

• UX als Fähigkeit im Scrum-Team ab Stunde 0 integrieren und die Fachkompetenz allen transparent machen.
• Das gesamte Scrum-Team befähigen, ständig miteinander kommunizieren zu können – und dies möglichst direkt.
• Teammitglieder ermutigen, miteinander zu arbeiten und gemeinsam einen Mehrwert für das Produkt zu generieren.

Für alles weitere helfen nach wie vor die 12 Prinzipien, die hinter dem agilen Manifest stehen.