Agile UX oder Agile gegen UX?

Ist diese Beziehung interessant, oder einfach nur schwierig?

Agile UX (Bild: Paul Kitchener via Flickr)

Man liest und hört oft die Frage, wie denn der UX-Prozess mit dem Agile-Prozess zu vereinbaren sei. Diese Frage ist schwierig. Das fängt schon damit an, dass UX und Agile überhaupt keine Prozesse sind.

Agile ist eine Prinzipien-Sammlung, die sich Entwickler ausgedacht haben um sich ihre tägliche Arbeit (Software Entwicklung) einfacher zu machen. UX hingegen ist die Wahrnehmung eines Systems. User Experience ist das subjektive Ergebnis einer Interaktion.

Es gibt viele verschiedene Wege die am Ende in einer User Experience münden. Eine Variante so eines vorgelagerten Prozesses wird oft etwas lapidar UX Design genannt. Fachlich korrekt ist aber die längere Bezeichnung Human-centered Design (ISO-Norm 9241-210) oder die im Volksmund gebräuchlichere Variante User-centered Design (UCD).

Ein im agilen Kontext bekannter Prozess ist Scrum. Agile UX ist also Quatsch. Die Frage muss korrekt lauten, wie läßt sich UCD mit Scrum vereinbaren?

Scrum und Human-centered Design haben durchaus Gemeinsamkeiten. Beide arbeiten iterativ. Das heißt man wiederholt Schritte, verbessert Arbeitsergebnisse sukzessive und nähert sich Schritt für Schritt einem Ziel (das ist nichts Neues, inkrementelle Software Entwicklung gibt es seit den frühen 60er Jahren).

Scrum und UCD können beide auch als eine Art Risikominimierung betrachtet werden. Allerdings während Scrum sich mit Symptomen befasst und versucht so schnell wie nötig das Falsche zu tun und daraus zu lernen, befasst sich UCD mit Ursachen und versucht so schnell wie möglich das Problem zu verstehen und das Richtige zu tun. Ein entscheidender Unterschied.

I had worked with SCRUM before, done training with Ken Schwaber and knew a few things from experience about how to achieve some success integrating a design team within SCRUM. This required the design team to work a “Sprint” ahead of the development team. But the new executive insisted that SCRUM had to be done by-the-book. Which meant, all activities had to be included within the same sprint, including design.

… schreibt Anthony Colfelt in Bringing User Centered Design to the Agile Environment. Sie spielt damit auf den Hang mancher Scrum Master an, Dual Track Scrum abzulehnen und tatsächlich alles in einen gemeinsamen Sprint quetschen zu wollen.

Spätestens seit dem Bestseller Lean UX kennen wir alle die Schritte die zum vermeintlichen Erfolg führen: Build, Measure, Learn. Interessanterweise kann man die Schritte im Human-centered Design ebenfalls auf diese drei Punkte komprimieren—aber mit leicht geänderter Reihenfolge: Learn, Build, Measure.

Liegt darin der Schlüssel für eine erfolgreiche Zusammenarbeit? …Oder ist die Sache doch nicht so einfach, weil zu unterschiedliche Paradigmen aufeinander treffen? In einem Kommentar zu obigem Artikel schreibt der bekannte UXler Anders Ramsey:

Let’s be very very clear: There is no typical Agile Process because Agile is not a process, it is a way of thinking about design, an attitude. More importantly, Agile is a completely different paradigm compared to waterfall – this is why UX folks keep banging their heads against the wall in frustration when trying to fit their roles into Agile. Trying to fit the role of Information Architect or Interaction Designer into an Agile team is like trying to figure out how to best put a steering wheel on a bicycle. Sure, it is possible to do it, but it will be awkward indeed, because a steering wheel was designed or an automobile paradigm and not a bicycle paradigm.

Das bereits erwänte Dual Track Scrum scheint eine breit akzeptierte Möglichkeit zu sein Human-centered Design mit Scrum zu verheireten. Allerdings setzt dieses Vorgehensmodell Konzepter und Designer dreifach unter Druck:

  1. man muss das zur Verfügung stehende Zeitfenster nutzen, um das Konzept und Design für den nächsten Entwicklungssprint vorzubereiten
  2. man ist Ansprechpartner für den aktuellen Entwicklungssprint
  3. man ist für die UX Qualtitätskontrolle des vergangenen Sprints verantwortlich

Das nachfolgenden Video zeigt stellvertretend für viele weitere Scrum Tutorials eines der Probleme mit Scrum (zumindest aus UX-Sicht): Anforderungen fallen bei Scrum größtenteils vom Himmel. Jemand hat eine Idee, Features werden priorisiert und dann geht schon die Entwicklung los.

Natürlich ist auch nie die Rede von Konzept, Design oder UX. Und natürlich fängt der Vortrag mit dem üblichen Waterfall Bashing an…

About Jan (501 Articles)
Informationsarchitekt und Konferenz-Veranstalter (IA Konferenz, die Konzepter-Konferenz: http://iakonferenz.org, MOBX Mobile UX Konferenz: http://mobxcon.com), Podcaster und Twitter Addict. Geboren in Prag, sesshaft in Berlin.

Leave a comment

Your email address will not be published.


*


css.php