Herausforderungen und Lösungen beim Zusammenspiel zwischen Usability und Scrum

In der Vergangenheit habe ich mich oft mit der Frage nach dem Zusammenspiel von User Experience und agilem Arbeiten beschäftigt. Ich habe über die Integration von Usability-Testing in agilen Projekten geschrieben oder darüber wie man Usability-Testing schneller und effizienter machen kann.
Heute möchte ich mich mit den bereits vorhandenen Frameworks beschäftigen, die sich mit der Frage nach der Integration von UX in Scrum & Co. beschäftigen.

UX und Scrum im Spannungsfeld

Eines der größten Probleme bei der Integration der UX in das Scrum-Framework, ist die unterschiedliche Herangehensweise an die Entwicklung. Denn obwohl beide eine iterative Herangehensweise haben, weisen sie ein paar elementare Unterschiede auf. Die Herangehensweise von UX sehe ich als den folgenden Prozess des User-Centered-Designs an. In jedem Schritt des Prozesses wird die User Experience mit verschiedenen Methoden optimiert, um eine möglichst hohe Usability / User Experience zu bieten. Dabei wird der Nutzer bei der Entwicklung des Produkts in den Mittelpunkt gestellt.

Abb 1.: UX im User Centred Design-Prozess

  • Big Picture: Scrum konzentiert sich auf das nächste Inkrement, während sich der UX/User Centred Design-Prozess (UCD) auf das Big Picture konzentriert
  • Detailierungsgrad der Konzepte: In Scrum wird oftmals eher ein Grobkonzept in Form eines MVP beschrieben, während sich der UCD auf ein sehr feines und detailliertes Konzept stützt.
  • Auch der Fokus auf das MVP steht bei Scrum im Vordergrund, während UCD das Konzept möglichst ganzheitlich zu beschreiben versucht.
  • Im UCD gibt es verschiedene Stabsstellen, die einen unterschiedlichen Fokus haben (vgl. Grafik), obwohl sich diese bei einigen Tätigkeiten überschneiden sind es oftmals unterschiedliche Personen. In Scrum dagegen sollte ein Team möglichst homogen sein und jeder sollte die Aufgaben des anderen zumindest theoretisch übernehmen können. Da auch schon die Stellen innerhalb der UX sehr heterogen sind wird es nur schwer möglich sein, diese auch mit den Entwicklern zu vereinen.

Damit ergeben sich einige Fragen, die sich bei der Integration von User Centred Design (UCD) in Scrum stellen:

  • Zu welchem Zeitpunkt macht es Sinn die Aufgabe der UX als Teil des Teams zu integrieren? Macht es überhaupt Sinn UX als Teil des Teams zu sehen oder sollte es eine Art Product Owner-Funktion haben, da sich aus der UX-Evaluation auch Aufgaben ergeben.
  • Damit ist auch die Frage verbunden, ob die UX in die Definition of Ready (eine Story ist so ausdefiniert, dass der Entwickler ohne weitere Fragen mit der Arbeit beginnen kann) eingebunden wird oder ob ein vorgelagerter Sprint zur Konzeption hier sinnvoll ist.
  • Sollte die UX als Stabsstelle agieren oder als Team-Element gesehen werden?

Abb. 2: UX-Ansätze im Sprint

Eine weitere Problematik bei der Integration ist die Vielfalt, die sich aus dem UCD ergibt. Die verschiedenen Disziplinen des UCD machen hier auch an verschiedenen Punkten des Scrum Prozesses Sinn (siehe Abb. 2). So spielt das klassische Usabilitytesting vor allem vor den Releases eine größere Rolle. User Requirements Enginnering dagegen dient dazu das Product Backlog zu füllen. Meiner Meinung nach gibt es nicht den einen Zeitpunkt in dem ein Produkt in einem Sprint getestet wird, auch wenn das Testen bereits in der Konzeption eine große Rolle spielen sollte, können Tickets selten exakt so umgesetzt werden, wie es aus der Konzeption hervorgeht.

User Experience in SaFE (Scaled Agile Framework): Centralised UX oder UX Governance

Zu den oben genannten Fragestellungen haben sich schon die ein oder anderen den Kopf zerbrochen und einige agile Frameworks haben versucht sich im Zuge der Skalierung von Scrum auf größere Projekte der Problematik anzunehmen. Eines davon, das ich heute vorstellen möchte ist SaFE, das Scaled Agile Framework. Im SaFE-Framework z. B. gibt es keine klare Definition, ob Usability in das Team integriert wird oder nicht, wohl aber Empfehlungen dazu. Zum einen schlägt das Framework vor, dass jedes Scrum-Team einen UX-Specialist hat, um die Aufgaben aus dem UCD abzudecken, zum anderen ein zentralisiertes UX-Team, das in einem eigenen UX-Backlog vorgibt was zu tun ist. Vorteile einer zentralen UX-Steuerung sind die Möglichkeit, dass man bereits etwas vorarbeiten kann und so im Zuge der Definition of Ready Inhalte zur Verfügung hat. Nachteil eines zentralen UX-Teams ist, dass hier ein Bottleneck für die Entwicklung entsteht. Eine Lösung kann ein Hybrid-Ansatz sein, bestehend aus einem UX Developer (ein Entwickler, der als UX-Spezialist fungiert und UX-Aufgaben übernimmt) innerhalb des agilen Teams und einer zentralen UX-Governance. Egal, wie die Aufgabe der UX gehandhabt wird, sie ist im Falle von SaFE immer ein Teil des Agile Release Trains (ART). In SaFE ist ART ein zentrales Konstrukt und jeder ART ist eine langfristige, selbstorganisierte, virtuelle Organisation, die gemeinsam plant, commited und ausführt.

Um die oben genannten Probleme der Unterschiedlichen Betrachtungsweisen von UX und Scrum zu umgehen wird in SaFE versucht, UX bestmöglichst in den gesamten Prozess zu integrieren und dafür den sogenannten Agile Release Train zu nutzen. Schnelles low-fidelity Prototyping, sich an die inkrementellen Prinzipien von Scrum und SaFE anzupassen und eine verstärkte Zusammenarbeit innerhalb des ART zwischen Entwicklern und den UXlern ist durch selbstbestimmtes Arbeiten intensiver und es kann schneller Feedback seitens UX gegeben werden und die agile Arbeit zu vereinfachen. Auch die Research Aktivitäten sind in den Stories eingebettet, um ein sauberes Testen zu garantieren. Last but not least ist auch das User Interface in den Akzeptanzkriterien verankert, um eine bessere Kultur für UX zu schaffen.

Portraitfoto: Daniel Wolf

Daniel Wolf

Senior User Experience Consultant

eresult GmbH

Bisher veröffentlichte Beiträge: 4

Ein Kommentar

Schreibe einen Kommentar

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