iteratec Blog

UX und Scrum, wie passt das z‘samm?

Geschrieben von Christoph Murczek | 24.09.2020 22:00:00

Wer nach den Begriffen Agile, Lean, Scrum oder UX sucht, findet viel Ärger und Frustration. Designer beklagen das Opfern der Kreativität auf dem Altar der raschen Ergebnisse, während Entwicklungsteams das Design als blockierend empfinden. Abseits von allgemeinen Weisheiten wie "…mache möglichst viel Designarbeit im Sprint…" gibt es scheinbar wenig verwertbare Erfahrung.

Inhalt

 

Ausgangssituation

In einem Kundenprojekt sind wir, iteratec, und eine Designagentur als gleichwertige Auftragnehmer beauftragt, eine öffentlich erreichbare Applikation zu liefern. Der bis zum Minimum Viable Product (MVP) anvisierte Zeitraum umfasst sechs Monate.

 

Der UX-Prozess

Im ersten Meeting, in dem wir die Zusammenarbeit geplant haben, stellte die Designagentur den Prozess vor, nach dem sie das Projekt umsetzen wollten.

Eine erste zeitliche Grobplanung sah vor, für die Define- und Design-Phasen ca. zwei Drittel der verfügbaren Zeit zu verwenden, um dann Entwicklung und Inbetriebnahme im letzten Drittel durchzuführen.

Scrum


Vom Kunden war gewünscht, den Auftrag nach Scrum zu entwickeln. Scrum [1] verwirklicht das Agile Manifest [2] sowie die damit verbundenen zwölf agilen Prinzipien, und hat das Ziel, rasch, idealerweise mit jedem Sprintergebnis, ein wertvolles Inkrement des Produkts an die Endanwender zu liefern, um damit Erfahrung zu sammeln. Dieses Feedback fließt in die Produktentwicklung ein und erlaubt so eine mögliche Fehlentwicklung rasch erkennen und korrigieren zu können.

Der Product Owner (PO) verwaltet dazu die geplanten Produkteigenschaften im Product Backlog. Gemeinsam mit dem Entwicklungsteam verhandelt er im Sprint Planning den Umfang des nächsten Produktinkrements, als Ausschnitt aus dem Product Backlog, genannt Sprint Backlog. Das Entwicklungsteam setzt diesen während des Sprints um, und demonstriert dem PO das Ergebnis im Sprint Review. Ist der PO damit zufrieden, wird das Inkrement ausgeliefert, um damit Feedback bei den Endanwendern einzuholen.

 


Die Recherche

Schon anhand der kurzen Prozessbeschreibung, bzw. -abbildungen, ist ersichtlich, dass die beiden Zugänge zur Produktentwicklung nicht kompatibel sind. Während die UX-Sichtweise immer das Produkt in seiner Gesamtheit behandeln will, betrachtet das agile Vorgehen nur die nächstwichtigen Eigenschaften. Um möglichst rasch zu einer produktiven Arbeitsweise zu kommen, begannen wir eine Recherche, um herauszufinden, welche Erfahrungen und Lösungsansätzen andere mit agilen Ideen hatten.

Lean UX

In Lean UX [3] beschreibt Jeff Gotthelf wie Eric Ries' Ideen von Lean Startup [4] auf UX Design angewendet werden können. Eine Idee wird als Hypothese in Form eines Minimum Valuable Product (MVP) formuliert. UX Designer entwerfen einen Prototyp und sammeln anhand von User Testing Daten.

Die Daten werden analysiert, und das daraus Gelernte bildet die Basis, um die Idee weiterzuentwickeln.
 
Klingt wunderbar! Wie in Scrum wird ein Produkt nicht nach einem Phasenmodell, sondern iterativ/inkrementell entwickelt. Beim Versuch die Anwendung von Lean UX im Projektalltag zu skizzieren, stießen wir allerdings schnell auf einige wesentliche Hürden:
 

  • Wie lässt sich diese Vorgehensweise in die rasche Taktung von Scrum einordnen?
  • Wie wird das Entwicklungsteam eingebunden?
  • Wann entsteht das Produktinkrement?

 
Lean UX gibt darauf leider keine Antworten. Der Fokus liegt hier ausschließlich auf UX-Design. Die tatsächliche Produktentwicklung ist als darauffolgende Phase angedacht. Wir sind also keinen Schritt weiter.

Design Thinking / Design Sprint

Der Begriff Design Thinking [5] wurde in den 90ern von David Kelley und Tim Brown bei IDEO erfunden. Sie kombinierten dazu Ideen und Vorgehensweisen, die in der Branche schon seit Jahren als eigenständige Werkzeuge angewandt wurden, in ein in sich stimmiges Konzept.
Dabei wird in jedem der Diamanten zuerst ein Problemraum eröffnet, um anschließend das Gesammelte zu bewerten und zu entscheiden welche der Ideen weiter ausgearbeitet werden soll.

 

Darauf aufbauend hat Jake Knapp bei Google Ventures den Design Sprint [6] definiert. Ein Design Sprint versteht sich dabei als Anleitung, wie ein Team von fünf bis sechs Personen in fünf Tagen eine Produktidee zu einem validierten Prototyp ausbauen kann. Für die Durchführung eines Designsprints hat Google das Design Sprint Toolkit [7] als Werkzeugsammlung veröffentlicht.
 
In fünf Tagen von der Produktidee zum Prototyp? Das klingt doch hinsichtlich Vereinbarkeit mit Scrum schon sehr vielversprechend! Bei genauerer Betrachtung stellt sich allerdings heraus, dass auch hier wieder ausschließlich UX Design auf Produktebene betrieben wird, während die tatsächliche Umsetzung der entworfenen Eigenschaften mit keinem Wort angesprochen wird.

Agile UX

Einen wesentlich konkreteren Ansatz beschreibt Desirée Sy 2007 in ihrem Artikel Adapting Usability Investigations for Agile User-Centered Design im Journal of Usability Studies [8] . Im Verlauf des Artikels leitet sie folgendes Modell her, nach dem UX Design und Entwicklung in einem iterativ organisierten Vorgehen parallel bearbeitet werden.

Während das Entwicklungsteam in Cycle/Sprint 0 das Setup der Entwicklungsumgebung vornimmt, beginnt das Design-Team bereits mit den Designarbeiten für die ersten Produkteigenschaften. Zu Beginn von Cycle/Sprint 1 übergibt das Design-Team sein Cycle/Sprint 0 Ergebnis an das Entwicklungsteam, damit dieses die Eigenschaften in das Produkt einbauen können. Während das passiert arbeitet das Design-Team bereits an den nächsten Eigenschaften, um so wieder die Vorgaben für das Entwicklungsteam im folgenden Sprint zu erarbeiten. Während dies in der Theorie sehr vielversprechend klingt, zeigen jedoch zahlreiche Postings, dass sich bei der Anwendung der Vorgehensweise genau die im Diagramm abgebildete Organisation manifestiert. Es bilden sich zwei Teams, die abgesehen von über den Zaun geworfenen Artefakten nicht miteinander kommunizieren. Schwierigkeiten, die beim Verarbeiten der Artefakte auftreten, können frühestens im darauffolgenden Sprint vom jeweils anderen Team bearbeitet werden. Die Durchlaufzeiten verlängern sich so um mindestens zwei Iterationen. All diese Probleme sollten doch eigentlich durch das agile Vorgehen abgeschafft werden. Sind Scrum und UX tatsächlich nicht vereinbar?

 

Zusammenfassung

Jede der recherchierten Vorgehensweisen bringt uns einem einsatzbaren Vorgehen einen Schritt näher. Bevor wir uns an die Lösung des scheinbaren Gordischen Knotens machen, sollten wir aber nochmal rekapitulieren, woran die Anwendung der genannten Methoden in einem nach Scrum organisierten Entwicklungsteam jeweils gescheitert sind:
 

Fokus lediglich auf UX Design
Mit Ausnahme von Agile UX betrachten alle Ansätze ausschließlich das Design. In einigen Publikationen wird sogar die mangelnde Verbreitung der Methoden beklagt, wo do so viele gute Ideen durch sie produziert würden. Fände sich doch nur jemand, der diese auch umsetzte…

Big UpFront Design (BUFD)
Design Thinking und dessen zeitlich begrenzte Variante Design Sprint legen den Fokus auf das gesamte Produkt. Damit öffnen sich der Analysis Paralysis ("Wir können doch nicht die Umsetzung beginnen, bevor alles ausreichend genau beschrieben ist") Tür und Tor.

Funktionale Teams
Agile UX nimmt zwar die Hürde der Mitbetrachtung der tatsächlichen Umsetzung, tappt dann aber in die Falle der funktionalen Teams (UX-Team, Entwicklungsteam). Im besten Fall sind die beiden Teams Teile derselben Organisation, und haben nur leicht divergierende Ziele (die Herstellung ihrer jeweiligen Artefakte). Im wahrscheinlich häufigeren Fall handelt es sich um zwei Dienstleister (Design-Agentur und IT-/Software-Dienstleister), die Ihre Aufwände auf die Bedienung ihrer jeweiligen Beauftragung optimieren. Die Integration der Zulieferungen obliegt dann dem Auftraggeber. Damit geht implizit auch einher, dass nach Kaizen betrachtet Verschwendung (Muda  [9] ) vorliegt. Da die Artefakte eben oft nicht zur Erreichung des höheren Ziels eines guten Produkts, sondern nur zur Bedienung einer Beauftragung erzeugt werden, kommt es hier oft zur Verschwendung in Form von Überproduktion (nicht weiterverarbeitete Teilergebnisse, z.B. Designs) sowie nicht benötigter bzw. unerwünschter Eigenschaften.
 
Gestaffelte Sprints
Egal ob Design und Entwicklung, oder die Entwicklung verschiedener Komponenten eines Systems (z.B. Frontend/Backend): Wann immer mehrere Teams Teilergebnisse über Sprintgrenzen aneinander übergeben, werden mehrere agile Prinzipien verletzt. Das übergebende Team produziert Muda in Form von unfertiger Arbeit. Weiter besteht die Gefahr des Muda durch das Herstellen nicht benötigter bzw. nicht gewünschter Eigenschaften über einen längeren Zeitraum, da das Halbfertigprodukt Design erst in das Produkt integriert werden muss bevor tatsächliches Kundenfeedback gesammelt werden kann. Kann das vorgelagerte Team, hier also das Design-Team nicht oder nicht genug liefern, entsteht im Entwicklungsteam Muda durch Wartezeit.
 
Aus diesen Betrachtungen lassen sich nun die Anforderungen ableiten, die ein integrierter Design-/Entwicklungsprozess erfüllen muss:
 
Iterativ-inkrementelle Produktentwicklung
Design und Entwicklung des Produkts passieren in kleinen Schritten, die aber immer einen Mehrwert für die Endkunden liefern. Dadurch erreichen wir die rasche Validierung zugrunde liegenden Annahmen des Designs und der Entwicklung.
 
Cross-Functional Team
Das Produktteam, bzw. in einem skalierten Setup jedes Teilprodukt-/Feature-Team, verfügt über alle Fähigkeiten, die notwendig sind, ein wertvolles Sprintergebnis zu liefern. In diesem Fall also ein gemeinsames UX-/Entwicklungs-Team.
 
Jedes Sprintergebnis ist ein Produktinkrement
„Funktionierende Software ist das wichtigste Fortschrittsmaß“, lautet eines der zwölf agilen Prinzipien. Verallgemeinert könnte man sagen „ein verwendbares Produkt ist das wichtigste Fortschrittsmaß“. Es ist auch die einzige Möglichkeit, tatsächliches, realistisches Feedback der Endanwender zu bekommen. Prototypen geben eine erste Indikation, da sie immer nur eine Simulation sind, bzw. nie im echten Leben verwendet werden. Auch alle Formen des Muda lassen sich nur unter dieser Maxime vermeiden.

Ein Lösungsansatz

Die Latte liegt hoch, aber die einfachen Probleme wurden eben schon alle gelöst. Wie zerschlagen wir nun den Gordischen Knoten des integrierten Design- und Entwicklungsprozesses unter den oben genannten Rahmenbedingungen?
 
Wird das Produkt um eine gänzliche neue Eigenschaft erweitert, wird zur Sprintmitte ein Refinement-Meeting angesetzt. Dieses nutzen wir, um die neuen Eigenschaften zu definieren. Dies passiert unter Mitwirkung aller an der Produktentwicklung beteiligten Rollen (Fachexperten, Endanwender, sowie das Scrum-Team bestehend aus Designer, Entwickler, Product Owner) in Form eines eintägigen Design-Sprints. Die Verkürzung auf einen Tag ist möglich, da wir entsprechend des iterativ-inkrementellen Vorgehens nur die nächst wichtigen Produkteigenschaft betrachten.
Im Sprint Planning sowie Sprint Review nehmen die gleichen Personen teil, die auch im Refinement beteiligt waren. Üblicherweise entstehen an einem solchen Refinement-Tag mehr Backlog Items als vom Entwicklungsteam in einem Sprint umgesetzt werden können. Im Planning muss daher die Priorisierung stattfinden, bei der Bedürfnisse der Endanwender gleichermaßen berücksichtigt werden müssen wie die der Business Agility. Im Sprint Review schließlich haben die Endanwender und Fachexperten/PO die Möglichkeit (und die Verantwortung!) sofort Feedback zum Sprintergebnis zu geben.

Die Beteiligung aller vom Produkt betroffenen Rollen hat mehrere Effekte:

  • Die Integration der Endanwender stellt sicher, dass der User-Fokus gleichwertig mit der Business Agility, vertreten durch den PO, die Grundlage der Produktentwicklung darstellt.
  • UX und Entwicklung arbeiten als ein Team an einem gemeinsamen Ergebnis: dem/den nächsten Produktinkrement(en).
  • Da die neuen Eigenschaften gemeinsam entworfen wurden, haben alle Beteiligten das gleiche Verständnis der zu lösenden Aufgabenstellungen sowie der gewählten Lösungswege. Missverständnisse und nicht umsetzbare Produkteigenschaften gehören so der Vergangenheit an.
  • Das Einholen des Feedbacks der Endanwender im Review Meeting stellt eine Minimalform eines kontinuierlichen User Testing dar.

 
Rückblickend betrachtet stellt sich die Frage, warum der Post so lang ist. Die Lösung ist doch recht einfach. Keep it simple, stupid sagen sinngemäß auch schon die agilen Prinzipien.

Noch Fragen?

Wie können Sie agile Methoden in Ihrer Organisation umsetzen, damit sie einen echten Mehrwert liefern? Erfahren Sie, wie wir Sie unterstützen können:

Mehr zu agiler Organisation
 

Christoph Murczek - arbeitet bei iteratec als leidenschaftlicher Product Owner und Scrum Master aus Überzeugung. Er ist Gründer und Hauptorganisator des Vienna Scrum Meetup als Austauschplattform für agiles Arbeiten und unterrichtet an mehreren Hochschulen agile Projektorganisation.

 

 
Vollständigen Beitrag anzeigen