UX im agilen Alltag

Viele Entwicklungsteams arbeiten heutzutage agil. Dies hat häufig unterschiedliche Gründe, manche haben vielleicht erkannt, dass die agile Arbeit dabei hilft die Entwicklung besser planen zu können, ändere wollen ihre Mitarbeiter mehr motivieren und binden, wieder andere machen es vielleicht nur, weil es alle machen. Egal welche Motivation hinter dem Wechsel zu agiler Arbeit steckt, feststeht, dass eine wirklich erfolgreiche agile Entwicklung nur dann funktioniert, wenn man sich dabei auch an den agilen Werten orientiert.

Um dies kurz Anzureißen, hier die vier wichtigsten Elemente die im agilen Manifest beschrieben werden:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das bedeutet es geht im Kern darum, die Entwicklung genau so zu machen, wie es mit dem Entwicklungsteam am besten funktioniert. Es geht darum funktionierende Software zu produzieren, auch im Sinne der Akzeptanz. Daher ist eine Zusammenarbeit mit dem Kunden auch ein Kernmanifest. Wenn etwas nicht passt, wird es angepasst, an der Software, am Konzept, aber auch am Prozess. Dies funktioniert vor allem durch eine ausgeprägte Fehler- und Feedbackkultur, d. h. man reflektiert in regelmäßigen Abständen den Status Quo, erkennt Fehler, wertschätzt diese und versucht etwas anderes.

Auf den ersten Blick widerspricht das dem Vorgehen bei der menschzentrierten Gestaltung wenig. Auch hier versucht man iterativ, die optimale Lösung für ein Nutzerbedürfnis zu finden. Dennoch ist zu beobachten, dass sich viele Firmen noch mit der Einführung eines UX Prozesses schwertun. Woran liegt das?

Scrum und UX

Wie beim Rugby sprintet man im Scrum die gesamte Strecke als Team und passt den Ball flexibel hin und her.

Eine häufig genutzte agile Methode ist Scrum.
Jedoch ist nicht agil = Scrum, was manche irrtümlicher Weise annehmen. Scrum ist lediglich ein Ansatz agil zu arbeiten. Es basiert auf der Idee, dass man ein homogenes Entwicklerteam hat, in dem jeder Entwickler die Aufgaben des anderen übernehmen kann. Daher kommt auch der Name Scrum (engl. für Gedänge), da die Metapher dahinter ist, dass man wie beim Rugby als Gruppe die gesamte Strecke läuft und den Ball flexibel hin und her passt. Dadurch wurde ein Prozess entwickelt, bei dem es nicht um die Planung von Ressourcen geht, sondern um die Planung von Aufgaben. Das Team kann eigenständig entscheiden, wie lange eine Person für die Erfüllung einer Aufgabe benötigt, egal wer sie bearbeitet. Man fokussiert sich bei der Planung immer auf das Inkrement, also den Teil der Software, der am Ende des Sprints (meist zweiwöchige Entwicklungsphase) fertig sein soll. Elemente der Software (Features) die nicht innerhalb des Sprints fertig gestellt werden, sind meist noch nicht im Detail nach Aufwand geschätzt und entsprechend geplant, man hat ehr eine grobe Idee, was da noch kommt. Der Vorteil in dieser Vorgehensweise besteht darin, dass man keine Zeit auf die Planung von Features verschwendet, die vielleicht nie implementiert werden, weil sich im Laufe der Entwicklung herausstellt, dass man sie nicht braucht oder sie anderes sein sollen als initial gedacht.

Bei der menschzentrierten Gestaltung hingegen versucht man meist, das sogenannte „Big Picture“ im Blick zu haben, um zu Recht auch wichtige Aspekte, wie die Konsistenz, nicht außer Acht zu lassen. Die Idee ist, dass man vor der Entwicklung schon alle Anforderungen des Nutzers aufgenommen hat und diese auch alle umsetzten muss. Die die nicht entwickelt werden müssen, sind keine Nutzungsanforderungen. Das gesamte Bedienkonzept steht im besten Fall bereits, bevor eine Zeile Code geschrieben ist.

Hier sieht man eine riesige Diskrepanz im Grundansatz. Erschwerend hinzukommt, dass viele Entwicklungsteams, selten an einer Neukonzeption arbeiten. Man bewegt sich nicht auf der grünen Wiese. In der Realität hat man aber auch nicht unendlich Zeit, um das perfekte Produkt zu liefern. Man hat häufig eine Deadline auf die man hinarbeitet und man muss schauen, was in dieser Zeit machbar ist. Dinge die nicht umsetzbar sind, werden runterpriorisiert oder gestrichen.
All das sind Aspekte die annehmen lassen, dass Scum und UX nicht vereinbar sind. Jedoch ist dem nicht so. Wenn das Team die agilen Werte verstanden hat, wissen sie, dass sie sich nicht starr am Scrum-Lehrbuch festhalten müsse. Das Team hat den Prozess wahrscheinlich bereits auf die eigenen Bedürfnisse und Gegebenheiten angepasst. Ist man also offen den Prozess den Bedürfnissen des Teams und des Produkts anzupassen, steht der Einführung von UX Methoden also erstmal nichts im Weg.

UX Methoden für den agilen Alltag

Der erste Schritt UX in die Entwicklung zu integrieren ist, diese als festen Bestandteil des Prozesses zu sehen. Dies kann beispielsweise dadurch vollzogen werden, indem ein UX Professional an den Meetings teilnimmt oder im besten Fall Teil des Teams wird. Dieser ist dafür zuständig, dass die Nutzeranforderung bei der Sprintplanung Beachtung finden. Priorisiert man die Aufgaben im Team könnte der UXler beispielsweise eine Stimme für den Nutzer bekommen.
Erste Entwürfe können von dem Konzepter selbstständig mit einem Prototyp getestet werden. Selbst wenn es nur ein schneller Guerilla Test auf dem Flur ist, bringt dies immer noch mehr als gar nicht zu testen. Die Ergebnisse eines Guerilla Tests sind immer mit Vorsicht zu genießen, da Mitarbeiter und besonders die Mitglieder des Entwicklungsteams immer eine vorgeprägte Meinung haben. Dieser muss rausgefiltert werden, da sie ggf. nicht der des Nutzers entspricht.

Regelmäßige Tests mit Nutzern helfen frühzeitig Feedback zu erhalten.

Die Königsklasse ist es jedoch, wenn das agile Team regelmäßig mit realen Nutzern testet. Dies funktioniert am besten bei einem User Feedback Day. Man plant in regelmäßigen Abstanden, z. B. jeden zweiten Sprint am Montag, einen Testtag. An diesem Tag testet man mit 5-6 Probanden und macht danach die Auswertung in einem Workshop mit dem Team zusammen. Dann hat man am nächsten Tag direkt die Ergebnisse, um diese in den kommenden zwei Sprints zu bearbeiten. Vorteil dieser strikten Planung ist, dass man sich selbst diszipliniert zu testen und in regelmäßigen Abständen sein Konzept überprüft. Zu agilem arbeiten gehört sehr viel Disziplin und Organisation, hier passt der User Feedback Day also sehr gut rein. Zudem kann man durch die User Feedback Days sehr schnell Fehler aufdecken. Also alles genau im Sinne der agilen Werte. (Mehr zum UFD lesen Sie hier.)

Das große Ganze im Blick

Bei der sogenannten „Dual Track Entwicklung“ müssen Informationen regelmäßig zwischen den zwei Teams ausgetauscht werden.


Die Frage wie man bei dem Fokus auf das Inkrement das große Konzept immer noch im Blick behält ist noch offen. Ein Ansatz den viele Teams hier fahren ist zwischen Discover und Deliver zu unterscheiden. Also die Phase in der man die Produktidee und das Konzept entwickelt und in der man sie produziert. Manche machen dies mit zwei Teams. Dabei ist das Discover Team dem Deliver Team immer einen Sprint voraus.

Nachteilig an diese Herangehensweise ist, dass in der Deliverphase Probleme und Fragen auftreten können, die das Discover Team so nicht abschätzen konnte. Hierfür braucht man gute Kommunikation und Abstimmung zwischen den Teams. Ein alternativer Ansatz ist, Discover und Deliver von einem Team machen zu lassen. Dies hat den Vorteil, dass das Team, welches später auch das Konzept umsetzt, bei der Entstehung dabei ist. Technische Hürden können dadurch frühzeitig erkannt und Lösungen gesucht werden. Zudem hat das Entwicklungsteam eine Bindung zu dem Konzept und fühlt sich dafür stärker verantwortlich.
Eine Methode um effektiv zu Konzipieren und dabei gleich auch zu teste, ist der Google Design Sprint. Dies ist eine Methode, die darauf basiert das man in strengen Zeitboxen arbeitet und durch den Wechsel zwischen Einzel- und Gruppenarbeit Ideen immer weiterentwickelt. Durch diese disziplinierte Vorgehensweise kann man Konzepte innerhalb von fünf oder vier Tagen entwickeln und Testen. Hat man sowieso einen regelmäßigen User Feedback Day, kann man diesen auch als Teil der Design Sprints verwenden.

Fazit

Es gibt keine klaren Regeln wie man UX am besten in den agilen Alltag integrieren kann. Wichtig ist, ganz nach den agilen Werten, Methoden zu testen, zu reflektieren und ggf. – falls es nicht funktioniert – anzupassen. Das Team sollte den Freiraum haben genau den Prozess für sich zu finden, der ihnen am besten hilft, den Nutzer mit in die Softwareentwicklung zu integrieren. Den stehen sich im Grunde die Werte von agiler Arbeit und menschzentrierter Gestaltung nicht gegenüber, sondern ergänzen sich.

Ein Kommentar

  • Ben

    Danke für die gute Einführung. Nach meiner Erfahrung ist die Integration von UX und Scrum eine große Herausforderung. Ein guter PO mit nutzerzentrierter Sichtweise ist ein Schlüssel. Auch die feste, enge und langfristige Einbindung von UXlern in das Scrum Team und die entsprechenden Rituale (Dailies, Refinements, Reviews usw…) ist ein Erfolgsfaktor. Und noch ein Hinweis von einem ehemalig Rugby-spielenden UXler: Das Bild unter „Wie beim Rugby sprintet man im Scrum…“ ist nicht aus dem Rugby, sondern vom American Football. In Letzterem gibt es leider auch gar keinen Scrum. 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.