Der Kerngedanke von Agile war der, dass man mehr darüber herausfindet, was man tun muss, wenn man einfach losgeht. Wenn man das nicht macht, hat man vielleicht einen disziplinierteren Entwicklungsprozess, kann aber nicht alle Vorteile des agilen Ansatzes ausschöpfen.
Das sagte Hugh Beyer von InContext mir, als wir darüber diskutierten, wie Teams den Übergang ins Agile-Zeitalter bewerkstelligen. Ich war der Meinung, Agile würde uns Interaktionsdesignern und UX-Professionals das Leben erleichtern, denn im Kern steht Agile für eine Philosophie der Iteration. Wir wissen seit längerem, dass der Prozess beflügelt wird, wenn das Interaktionsdesign Iterationen durchläuft.
Doch laut Hugh sind Sprints, also Entwicklungszyklen von zumeist zwei bis vier Wochen Dauer, nicht dasselbe wie Iterationen im Zusammenhang mit Interaktionsdesign:
Wenn ich mit agilen Praktikern spreche, frage ich sie gerne: "Wie lange iteriert Ihr an einem bestimmten Stück Funktionalität, um es gut hinzubekommen? Drei Sprints?" Niemand meldet sich. "Zwei Sprints?" Niemand meldet sich. "Einen Sprint?" Jetzt gehen ein paar Hände hoch. Die Idee, zurückzugehen und die Funktionalität zu überarbeiten, ist eine harte Sache – organisatorisch, emotional und praktisch –, denn die Planung gerät ins Rutschen. Also ja, wir mögen die Idee der Iteration. Die Aktualität der Iteration interessiert uns dagegen weniger.
(Das gesamte Gespräch können Sie hier hören oder im Transkript nachlesen.)
Agile Teams iterieren im Rahmen mehrwöchiger Sprints, und ihre Kosten sind zu hoch. Ein Sechs-Mann-Team investiert in einen Drei-Wochen-Sprint 90 Personentage. Wenn sie am Ende bemerken, dass sie etwas gebaut haben, dass die User nicht nutzen können, haben sie eine Menge Aufwand in diese Erkenntnis gesteckt.
Hugh ist der Meinung, dass genau das zum Rückfall in die alten Wasserfall-Verhaltensweisen führt, obwohl die Leute behaupten, agil zu arbeiten:
Du verbringst einige Zeit damit, die Funktion auszuarbeiten, ganz so, wie Du es immer getan hast. Dann – und mit einer vagen Vorstellung von Schnelligkeit – planst Du die Funktion in Deinen Sprint ein und dann legst Du los. Es ist genau wie beim traditionellen Entwicklungsprozess, außer dass Du bei jedem Sprint eine Ausgangsbasis hast. Diese Mentalität führt zu der Idee, dass ich, wenn ich nicht meine gesamte Funktionalität wie geplant in diesem Sprint implementiert bekomme und sie in den nächsten Sprint schieben muss, versagt habe. Ich bin nicht gut.
Die Sache ist die, dass es gar nicht so laufen muss. Es ist möglich und tatsächlich höchst erstrebenswert, Low-Cost-Iterationen in den Entwicklungsprozess zu integrieren. Der Trick besteht darin, Iteration zu etablieren, die kürzer als ein Sprint sind, indem man nach Techniken Ausschau hält, die die Kosten von Iterationen signifikant senken.
Die Iterationskosten durch Papier-Prototypen und Design-Studios senken
Ein Ansatz zur Senkung der Kosten von Iterationen ist die Erstellung von Papier-Prototypen. Innerhalb von ein paar Stunden kann ein Sechser-Team einen funktionierenden Prototypen praktisch jeder Interaktion bauen, komplett auf Papier. Für unseren kompliziertesten Prototypen haben wir zwei Tage gebraucht, und dabei haben wir den Entwurf intensiv ausprobiert und überarbeitet. Diese zwei Tage waren gefüllt mit einem Dutzend großen Iterationen des Interaktionsdesigns und am Ende kam etwas heraus, das sich substanziell von unserem ersten Entwurf unterschied.
Während man beim Paper-Prototyping schnell Ideen verfeinern kann, kommen Design-Studios ins Spiel, wenn man die beste Idee überhaupt finden will. Mit einem Design-Studio-Tool skizziert ein Sechser-Team jede Menge Ideen so schnell wie möglich. Es arbeitet über eine Reihe kurzer Zeiträume hinweg an Skizzen, dann folgen Kritik und Diskussion, dann weitere Skizzen und weitere Kritik, und schließlich hat das Team Dutzende Ideen generiert, um das weite Interaktionsdesignfeld zu erforschen.
Beide Techniken sind schnell, weil sie auf den schweren Überbau verzichten, der bei der Umsetzung einer Idee in Code entsteht. Da das Team innerhalb weniger Tage ernsthafte Fortschritte macht, zahlt sich dieses Vorgehen schnell aus und fügt sich prima in die Rahmenbedingungen der agilen Methoden ein.
Die Iteration zerlegen
Eine gut durchgeführte Iteration besteht aus vier Schritten: der Planung, der Implementierung, der Bewertung und dem Lernprozess. Im Planungsstadium entscheidet das Team, was bei der Iteration herauskommen soll. Während der Implementierung erstellen sie den Artefakt (als Prototyp oder als programmierte Version der Interaktion). Beim Bewerten sammelt das Team Informationen darüber, wie gut sich mit dem Element erreichen lässt, was mit ihm erreicht werden soll. Und im Stadium des Lernens extrahiert das Team die Lektionen aus der Iteration, die künftig wertvoll sein werden. (Ausführlich ist dies im Artikel Anatomie einer Iteration beschrieben.)
Diese vier Schritte scheinen einfach zu sein, aber überraschend viele Teams lassen einige aus. Die meisten Teams haben keine Probleme mit der Implementierung – immerhin ist das ja auch das Herzstück einer Iteration. Den Schritten Bewerten und Lernen widerfährt allerdings weniger Aufmerksamkeit als nötig, und der Planungsschritt wird oft komplett ignoriert.
Konzentration auf das schnelle Bewerten
Beim Bewerten einer Iteration im agilen Prozess stellt man die folgende Frage: Hat uns diese Iteration näher an etwas herangebracht, das unsere Nutzer brauchen oder wollen? Ein Nein am Ende eines Sprints bringt uns in Schwierigkeiten. Aber wenn wir nur wenig Zeit, sagen wir ein paar Stunden (oder auch nur Minuten) mit etwas verbracht haben, ist ein Nein okay, vor allem wenn es dann mit einem "Warum nicht?" weitergeht. Von hier an können wir weiter iterieren und kommen diesmal dem Ziel hoffentlich näher (oder lernen etwas Wichtiges).
Wenn wir mit einem Design-Studio arbeiten, planen wir die erste Iteration, indem wir fragen: Welche verschiedenen Wege gibt es, die Dinge für die Nutzer zu verbessern? Diese Iterationen sind erfolgreich, wenn wir diverse Alternativen produziert haben und die Möglichkeit hatten, sie auf Erfolg zu prüfen. (Das ist am einfachsten, wenn man Nutzerforschung mit echten Usern betrieben und ihnen bei der Arbeit zugesehen hat, denn daraus gewinnen Sie Informationen darüber, was "besser" eigentlich bedeutet.) In späteren Iterationen können wir anfangen zu schauen, wie sich die Ideen verfeinern lassen, indem wir von einem Entwurf zum nächsten gleiten.
Mit einer Technik wie dem Paper-Prototyping können wir etwas erschaffen, das nutzbar genug ist, um es echten Usern vorzulegen. Dafür bauen wir ein interaktives Modell vom unserer Meinung nach besten Entwurf, dann spielt ein Teammitglied den Computer und wir bitten die Nutzer, richtige Aufgaben mit dem Prototypen zu erledigen. Davon ausgehend, bewerten wir den Entwurf, indem wir vor dem Hintergrund der erledigten Aufgaben fragen: Wo funktioniert der Prototyp gut und wo trifft er nicht ins Ziel?
Die erfolgreichsten Teams sind die, die im Rahmen einer Iteration so viel Zeit in die Bewertung investieren wie in die Implementierung. Weil diese Techniken so schnell sind, können sie bei der Entwicklung des Interaktionsdesigns frühzeitig eingesetzt werden. Und weil sie nicht teuer sind, erlauben sie dem Team, die notwendigen Fehler zu begehen, um das Interaktionsdesignfeld zu erkunden, ohne kostspielige Ressourcen für die Erstellung von Code zu vergeuden.
Interaktionsdesign ist ein Teamsport
Es ist verlockend, die UX-fokussierten Teammitglieder diese frühe Arbeit verrichten zu lassen, während der Rest rausgeht und sich anderen Aktivitäten widmet. Aber den größten Nutzen entfalten diese frühen Iterationen durch die Diskussionen und die Einsichten, die aus ihnen entstehen. Die erfolgreichsten Teams binden alle Personen, die das Produkt beeinflussen - inklusive der Entwickler und Entscheider - in die Design-Studio- und Paper-Prototyping-Arbeiten mit ein.
Diese Iterationen führen zu einem gemeinsamen Verständnis vom Ziel, das das Team erreichen will. Wenn es dann in späteren Stadien richtig intensiv wird, bewahrt dieses gemeinsame Verständnis vor zeitraubenden Debatten und beschleunigt die Entscheidungsfindung – und führt schneller zu einem besseren Interaktionsdesign. Letztlich ist die schnelle Entwicklung toller Interaktionen ja der Grund dafür, dass wir den Übergang zu Agile vollziehen, oder?
Dieser Artikel wurde im Original am 21. März 2012 unter dem Titel Cost Effective Approaches to Iteration in Agile UX
