Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Ratgeber

Ein gutes Doppel: Scrum und User-Experience-Design erfolgreich anwenden

    Ein gutes Doppel: Scrum und User-Experience-Design erfolgreich anwenden

(Foto: M S / Flickr Lizenz: CC BY-SA 2.0)

Die Bedeutung der User Experience bei der Software-Entwicklung ist im Smartphone-Zeitalter wichtig wie nie. Doch wie lassen sich User-Experience-Design und der Scrum-Prozess vereinen?

Inzwischen gibt es zahlreiche Workshops, umfassende Literatur und eine große Anzahl erfahrener Scrum-Experten. Im Scrum-Kontext wurde es bisher jedoch vernachlässigt, andere Elemente und fachliche Disziplinen, die essenziell für ein starkes Produkt sind, zu integrieren – wie beispielsweise das User-Experience-Design. Eine gute User Experience (UX) führt dazu, dass Anwender ein Produkt bzw. eine Software gerne nutzen und ist damit ein wesentlicher Erfolgsfaktor.

Dennoch treten in der Praxis das User-Experience-Design und der Scrum-Prozess bisher meist nur nebeneinander an und haben wenige Berührungspunkte: Das UX-Design – vom User-Research über die Definition von Personas bis hin zur Erarbeitung von Skizzen und Wireframes – wird oft im Voraus erstellt und dann für die Umsetzung dem Entwicklungsteam übergeben. Erschwerend kommt hinzu, dass meist externe, spezialisierte Agenturen – die oft nach der klassischen Wasserfall-Methode arbeiten – das User-Experience-Design gestalten. Das liegt zumeist daran, dass bei der Gründung der seit längerem bestehenden IT-Unternehmen das Thema UX noch nicht so sehr im Vordergrund stand wie heute.

Mit der zunehmenden Bedeutung und Verbreitung des Internets – bis auf die Bildschirme unserer Smartphones – haben sich die Ansprüche der User an eine Software jedoch verändert: Sie legen deutlich mehr Wert auf das Design und die Nutzerführung einer Software oder einer Internet-Anwendung. Um den stetig steigenden Ansprüchen der User gerecht zu werden und nicht zuletzt, um Marktanteile zu halten oder gar auszubauen, muss das UX-Design den User nicht nur bei der Anwendung unterstützen, sondern ihm auch ein gutes Gefühl bei der Nutzung der Software vermitteln. Je weniger Software-Unternehmen also auf ein optimales User-Experience-Design verzichten können, umso wichtiger ist es, diese Disziplin mit dem Scrum-Prozess zu verzahnen, der von ihnen meist für die Entwicklung eingesetzt wird. Denn nur wenn das User-Experience-Design und die Entwicklung im Rahmen eines agilen Prozesses gemeinsam antreten, steht am Ende ein Sieg: ein erfolgreiches Produkt, das nicht nur funktioniert, sondern das die Nutzer auch gerne anwenden.

Die drei wichtigsten Aspekte für eine erfolgreiche Integration von UX-Design in den Scrum-Prozess

Erfolgsfaktor 1: Räumliche Nähe – für mehr Austausch und gegenseitiges Verständnis

Eine gelungene, agile Zusammenarbeit zwischen UX-Designern und Softwareentwicklern wird durch viele Faktoren bestimmt, der Hauptfaktor aber ist das Team selbst. Häufig ist jedoch das Verhältnis zwischen Designern und Entwicklern eher angespannt. Das liegt nicht selten daran, dass beiden Gruppen nur wenig über die Arbeitsprozesse der jeweils anderen Gruppe wissen. So ist es für Designer oft nicht leicht nachzuvollziehen, wie die Entwickler mit den von ihnen zur Verfügung gestellten Designs weiterarbeiten. Die Entwickler wiederum können sich häufig kein Bild von den Prozessen machen, die Designer durchlaufen, um ein valides Konzept zu gestalten. Für beide Seiten ist es mitunter sehr intransparent, was die jeweils andere Gruppe in ihrer täglichen Arbeit leistet.

(Grafik: Shutterstock.com)
(Grafik: Shutterstock.com)

Aufklärungsarbeit seitens der Projektleitung und der Teammitglieder selbst kann hier zunächst ein grundlegendes Verständnis schaffen. Dabei sollte erklärt werden, was die Aufgaben der einzelnen Rollen sind und inwiefern sich durch die Integration der Designer auch Prozesse in der Softwareentwicklung anpassen müssen. Es ist wichtig, dass alle Teammitglieder verstehen, dass nur durch ein gutes Zusammenspiel beider Prozesse – User-Experience-Design und Softwareentwicklung – ein gelungenes Produkt entstehen kann.

Um das Verständnis für die Arbeit der jeweils anderen zu verbessern, ist räumliche Nähe ein wesentlicher Aspekt: Wenn Designer und Entwickler zusammen im gleichen Raum tätig sind, bekommen sie mit, woran der jeweils andere arbeitet. Sie können sich gegenseitig Fragen stellen und/oder ihre Arbeitsschritte wie etwa Designs oder Softwarearchitektur-Bilder sichtbar im Raum anbringen. Durch das offensichtliche Visualisieren der aktuellen Arbeiten können einfacher und schneller Gespräche und Diskussionen entstehen. Diese Kommunikation – die weitaus häufiger stattfindet, wenn ein Team in einem Raum sitzt – fördert den kontinuierlichen Austausch, auch im Hinblick auf die technische Realisierung von Design-Ideen. Kurze Kommunikationswege führen dazu, dass Fragen häufiger gestellt und schneller geklärt werden, und wirken sich damit positiv auf das Produktergebnis aus.

Wenn es zeitlich möglich ist – und das entsprechende Fachwissen vorliegt – können die Designer die Entwickler auch bei der Programmierung unterstützen, etwa im Bereich der Frontend-Entwicklung. Der Vorteil: Selbst entworfene Designs lassen sich auch gleich technisch umsetzen und somit auf ihre Machbarkeit prüfen. Umgekehrt können sich auch die Entwickler im Rahmen des Scrum-Prozesses an der Erstellung des User-Experience-Designs beteiligen, etwa indem sie Mockups oder Prototypen erstellen.

Finde einen Job, den du liebst

5 Reaktionen
Alex

Meine Erfahrung als Agile Coach zeigt, dass die Integration von UX und Design in das Scrum-Team eine wesentliche Voraussetzung für eine erfolgreiche Produktentwicklung ist. Gleiches gilt auch für Tester, Ops bzw. alle Expertisen, die benötigt werden, damit ein Team ein Produkt möglichst unabhängig entwickeln kann. Das fällt für mich unter Cross-functional Teams.
Bisher hält sich aber manchmal noch die Idee, dass das Interface und das Design möglichst vollständig vorab entwickelt werden und im Nachgang von den Entwicklern lediglich umgesetzt werden. Das entspräche aber eher einem Mini-Wasserfall im agilen Gewand.
So früh wie möglich sollten Prinzipien und Guidelines erstellt werden, damit sich das Produkt am Ende wie "aus einem Guss" anfühlt. User-Stories bis ins kleinste Detail zu spezifizieren - womöglich schon im Sprint 0 und pixelperfekt - ist unmöglich und widerspricht dem Ziel agiler Methoden. Das gleicht eher klassischen Vorgehensweisen.
Ist es nicht sinnvoller, dass das gesamte Team gemeinsamen Guidelines folgt, Stories gemeinsam definiert und auch gemeinsam umsetzt?
Für neue (besonders knifflige) Features können die Teammitglieder mit ihren unterschiedlichen Expertisen regelmäßig und parallel zum aktuellen Sprint (Timeboxing), gemeinsame Product-Discoveries durchführen, wo auf UX und Designfragen eingegangen werden kann und auch die technische Machbarkeit überprüft wird, wo auch verschiedene Varianten ausprobiert und Prototypen evaluiert werden.
Die Ergebnisse und Erfahrungen daraus fließen dann in die entsprechenden Stories ein. Der Vorteil ist, dass das Team frühzeitig eine gemeinsame Richtung erarbeitet und alle das gleiche Zielbild im Kopf haben. Das Team beschäftigt sich so noch viel mehr mit dem eigenen Produkt!
Zudem wird durch diesen integrativen Ansatz die Distanz zwischen einzelnen Expertisen abgebaut und gegenseitiges Verständnis aufgebaut - am Ende benötigen wir ja EIN funktionierendes Team. Auch jeder Entwickler kann mit der aufgesetzten Kundenbrille wertvollen Input zur Produktentwicklung geben und nicht nur Code hacken ;)

PS: Soweit ich mich entsinne, ist der PO per Definition für die Bestimmung und Kommunikation von Wert und Nutzen einer Story verantwortlich, niemand sonst. Die Informationen dafür können aber natürlich von jedem aus dem Team oder von außerhalb kommen.
PPS: Räumliche Nähe ist immer vorteilhafter und kann gleichwertig nur schwer durch Tools ersetzt werden. Es ist aber nicht unmöglich.

Antworten
derDoubleD

Hier die Slides eines passenden Erfahrungsberichts: Agile UX - oder We have not failed. We've just found 10.000 ways that didn't ... #agile #experience http://www.slideshare.net/derDoubleD/agile-ux-oder-we-have-not-failed-weve-just-found-10000-ways-that-didnt-work-nach-edison via @SlideShare

Antworten
Andre Böker
Andre Böker

räumliche Nähe ist überhaupt nicht relevant. Wir nutzen fast täglich Skype mit Bildschirmübertragung in der Entwicklung von Verwaltungssystemen.

Antworten
derDoubleD

Hallo Andre. Super, dass das bei euch so klappt - kann und muss deswegen nicht allgemeingültig sein. Was sind aus deiner Sicht die Erfolgsfaktoren, dass dieses Remote-Arbeiten funktioniert?

Antworten
Andre Böker
Andre Böker

Hallo DoubleD,

am besten sind gleiche Arbeitszeiten oder eine Abstimmung, wann man über Vorlagen und Lösungsbeispiele, konkrete Aufgaben, erreichte Ergebnisse, gewonnene Erfahrung, erkannte Fehler und abgeleitete Verbesserungen spricht.
Zeigt man den Entwicklern nicht, dass man die Lösung und Probleme bereits kennt, liefern sie nur das nötigste ab und das ist in der Regel nur ausreichend.

Mehr möchte ich an dieser Stelle nicht sagen.

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Hinweis

Du hast gerade auf einen Provisions-Link geklickt und wirst in Sekunden weitergeleitet.

Bei Bestellung auf der Zielseite erhalten wir eine kleine Provision – dir entstehen keine Mehrkosten.


Weiter zum Angebot