Lean & Agile – es gibt wohl kein Blog zur Produktentwicklung, Programmierung oder UX, in dem nicht alle paar Wochen mindestens ein Artikel zu diesen Themen erscheint. Doch dabei geht es oft wild durcheinander mit den Begriffen – „agile“ ist nicht gleich „lean“ und wer agile arbeitet, arbeitet nicht zwingend lean. Und gerade mit der agilen Arbeitsweise tut man sich als UX-Experte manchmal schwer. Bis heute gibt es keine goldene Regel dafür, wie man sich als Verantwortlicher für die UX im agilen Prozess einbringt. Daher habe ich dir hier die wichtigsten Punkte agiler und leaner Methoden zusammengefasst. Und vor allem siehst du, wann du was davon in deiner Produktentwicklung sinnvoll einsetzen kannst.
Agil, also beweglich und flexibel, will jeder sein. Es gibt heute kaum noch ein Unternehmen, das nicht von sich behauptet, agil zu arbeiten. Aber was steckt wirklich dahinter? Was ist der Unterschied zu lean? Und wie bringe ich das beides zusammen mit User Centered Design (UCD), also nutzerzentrierter Produktentwicklung? (Die Grundlagen des UCD habe ich kürzlich hier im Blog erklärt: UCD in deine Produktentwicklung integrieren
Im Folgenden geht es auch um die Frage: Warum sollte ich überhaupt agil oder lean arbeiten? In welchen Fällen ist das sinnvoll, in welchen nicht?
Was ist agile Entwicklung?
Das Prinzip Agile kommt aus der Software-Entwicklung und ist mittlerweile schon ungefähr 20 Jahre alt. Programmierer waren frustriert und Verantwortliche genervt, weil kaum ein Software-Projekt pünktlich fertig wurde und kaum ein Programm einigermaßen fehlerfrei lief. Das war viel Stress für alle Beteiligten und mangelhafte Qualität war die Folge – kein besonders schöner Zustand. Grund war, dass Softwareprojekte in den 1990er-Jahren so groß geworden waren, dass es kaum mehr möglich war, sie vernünftig zu planen. Zu viele Menschen machten bei solch einem Unternehmen mittlerweile mit, zu viele Unwägbarkeiten kamen hinzu und zu lange dauerten solche Projekte.
Da war es Zeit für einen Befreiungsschlag. Der kam 2001 mit dem Agile Manifest, das die Programmierer Jim Highsmith und Alistair Cockburn zusammen mit 15 Kollegen verfassten. Darin fordern sie unter anderem, funktionierende Software stärker zu gewichten als umfassende Dokumentation. Oder auch, die Zusammenarbeit im Team und mit dem Kunden zu priorisieren.
Es gibt viele verschiedene agile Prozesse. Am bekanntesten sind:
- Scrum
- Kanban
- Extreme Programming
In der Software-Entwicklung hat sich das agile Vorgehen mittlerweile fest etabliert. Nur noch selten trifft man ein Team von Programmierern, das nicht nach einem der agilen Prozesse vorgeht. Nur sehr kleine Projekte werden noch klassisch nach dem so genannten Wasserfallmodell umgesetzt. Dabei wird eine Phase nach der anderen durchlaufen – nach dem Festlegen der Anforderungen kommt die Umsetzung, dann die Programmierung, dann der Test und schließlich wird die fertige Software ausgeliefert.
Das klassische Wasserfallmodell
Bild: Paul Hoadley, Paul Smith and Shmuel Csaba Otto Traian
Ziel: den Auftraggeber so früh wie möglich miteinbeziehen
Beim agilen Vorgehen dagegen setzt man auf Iterationen. Ziel ist, so früh wie möglich schon Teile der Software zu haben, die lauffähig ist. Diese kann dann getestet werden und sie kann dem Auftraggeber vorgelegt werden. Dieser sieht so früh, ob die Entwicklung in die richtige Richtung geht und ob die Software seine aktuellen Anforderungen erfüllt.
Unzählige Studien haben gezeigt: Mit diesem Vorgehen lassen sich viele Probleme bei der Software-Entwicklung vermeiden oder zumindest verringern. Die Wahrscheinlichkeit, dass ein Projekt erfolgreich abgeschlossen wird, ist wesentlich höher, wenn man auf einen agilen Prozess setzt.
Die Vorgehensweise nach Scrum
Bild: Dr. Wüpping Consulting
Von der Programmierung in die Produktentwicklung
Viele waren so begeistert von der agilen Vorgehensweise, dass sie diese von der Programmierung auf andere Bereiche übertragen haben. Am naheliegendsten ist es, auch generell in der Produktentwicklung agil zu arbeiten, nicht nur bei der Programmierung. Was dabei gut passt, sind einerseits die Iterationen und andererseits die Möglichkeit, frühzeitig Zwischenstände präsentieren zu können. Diese zwei Sachen sind so effektiv, dass es das Schlagwort „agil“ sogar in die Vorstandsetagen geschafft hat.
Die grundlegenden Vorteile der agilen Programmierung wurden übernommen, also:
- Anpassungsfähigkeit
- Kommunikation
- Geschwindigkeit
Denn die Probleme, die es in der Software-Entwicklung gab, gibt es auch bei vielen anderen großen Projekten: Verpasste Abgabetermine, sinkende Motivation durch zunehmenden Stress, Überarbeitung der Projektbeteiligten und mangelnde Qualität des Ergebnisses.
Um die drei Ziele Anpassungsfähigkeit, Geschwindigkeit und Kommunikation zu erreichen, nutzt man ein wichtiges Prinzip der agilen Entwicklung: Unterteile jede Aufgabe in möglichst viele kleine. Das sichert dir Erfolgserlebnisse (das schöne Gefühl, sagen zu können: „Schon wieder etwas geschafft!“). Und außerdem hast du dann sehr früh im Projekt etwas, was du zeigen kannst (Geschwindigkeit). Und darüber kannst du dann mit den anderen Projektbeteiligten sprechen (Kommunikation). Daraus ergibt sich früh wertvolles Feedback und du kannst die Richtung korrigieren, wenn sie nicht perfekt stimmt (Anpassungsfähigkeit).
Ein Scrum-Team trifft sich zum Daily Scrum Meeting
Und zum Schluss noch ein wichtiger Punkt: Noch ein wichtiger Teil des agilen Arbeitens ist, nicht in festgelegten, starren Strukturen zu arbeiten. Sondern es sollten im Idealfall Teams entstehen, die rollen- und abteilungsübergreifend zusammengesetzt sind. Durch diese vielen Sichtweisen stellst du sicher, dass keine Aspekte vergessen oder zu spät erkannt werden.
User Research und Agile in der Praxis
Soweit klingt das alles ganz hervorragend mit der agilen Arbeitsweise. All diese Sachen kann man als UX-Experte eigentlich nur gut finden. Und doch haben viele UX-Kollegen mit der Arbeit in agilen Teams so ihre Probleme. Woher kommt das?
Ein Problem liegt darin, dass insbesondere beim agilen Vorgehensmodell Scrum sehr früh im Projekt mit der Programmierung begonnen wird. Als User Researcher wollen wir aber am Anfang einige Dinge über unsere Zielgruppe lernen. Wir wollen erst mal verstehen, wer diese Menschen sind, was deren Probleme sind und in welcher Situation sie das Endprodukt nutzen sollen/wollen. Finden wir dabei heraus, dass eine Grundidee für unser Produkt nicht funktioniert, dann müssen wir möglicherweise noch mal von vorn beginnen mit der Konzeption, vielleicht sogar noch mal in die Ideenfindung einsteigen. Sind die Programmierer dann aber schon fleißig am Codeproduzieren, dann bekommen wir möglicherweise ein Problem.
Der Sprint vor dem 1. Sprint: Sprint 0
Bewährt hat sich daher der so genannte Sprint 0. Sprints nennen sich die Arbeitsabschnitte, an deren Ende jeweils ein funktionierendes Stück Code stehen soll. Ein Sprint dauert meist zwei Wochen, manchmal auch nur eine, selten bis zu vier Wochen.
Im Sprint 0 wird, anders als bei allen anderen, noch nicht Code produziert. Die Programmierer schaffen hierbei das Fundament der Software-Architektur, setzen eventuell Server auf und legen ein Programmier-Framework fest. In diesem Sprint 0 können wir auch all die Dinge tun, die während der laufenden Umsetzung schon getan sein sollten: Wir sammeln also Informationen über die Nutzer und mögliche Nutzungskontexte. Jetzt ist also die Zeit für grundlegende User Research-Arbeit. Vor-Ort-Beobachtungen, Fokusgruppen, Tagebuchstudien, Card Sorting, Persona-Erstellung etc. haben hier ihren Platz. Und sogar erste Nutzertests von Papierprototypen, Klickdummies oder Konkurrenzanwendungen sind denkbar.
Unbedingt vermeiden solltest du „Big design up front“. Also die klassische Methodik aus dem Wasserfallprinzip: Am Anfang werden alle Anforderungen festgelegt und dann wird umgesetzt. Dazu ist der Sprint 0 nicht da. Im Sprint 0 liegt der Fokus ganz klar auf den Nutzern und ihren Bedürfnissen – noch gar nicht darauf, wie ihr diese Bedürfnisse bedient und das programmtechnisch umsetzt.
Erkenntnisse gewinnen während des laufenden Projekts
So haben wir am Anfang etwas Zeit, die grundlegenden Eckdaten festzulegen.
Wenn das Projekt dann läuft, also ab Ende von Sprint 1, nehmen wir das Ergebnis des jeweils vorhergehenden Sprints und machen idealerweise Nutzertests damit. So können wir während des laufenden Projekts immer wieder Erkenntnisse gewinnen, was den Nutzern Probleme macht, was gut ankommt und was man verbessern könnte. Die Ergebnisse fließen dann in die nächste Sprintplanung ein.
Das UX-Team ist also immer dreifach gefordert:
- beim Testen der Ergebnisse aus dem vorigen Sprint;
- bei der Unterstützung der Umsetzung im laufenden Sprint;
- bei der Vorbereitung des nächsten Sprints.
Das klappt in einigen Teams sehr gut, in anderen gibt es immer mal wieder Probleme. Nachdem diese Arbeitsweise noch immer neu ist, bleibt dir nichts anderes übrig, als in jedem neuen Projekt mit deinem jeweiligen Team herauszufinden, was für euch funktioniert und was nicht. Aber es lohnt sich auf jeden Fall – du wirst viel lernen und die Qualität des Ergebnisses wird immer besser sein!
Was bedeutet „lean“?
„Lean“ heißt schlank und erfreut sich schon seit Jahrzehnten als Schlagwort im Business-Umfeld großer Beliebtheit. Manche führen die Grundideen sogar zurück auf Henry Ford, den berühmten Autobauer, dem die Erfindung des Fließbandes zugeschrieben wird. Den Begriff „lean“ führten amerikanische Forscher ein, als sie in den 1980er-Jahren die Produktionsmethoden beim japanischen Autobauer Toyota untersuchten. Sie beschrieben den dortigen Prozess als Lean Production.
Warum war Toyota so erfolgreich geworden? Hier produzierten die Maschinen in der Fabrik nicht einfach jeweils so viel, wie eben maximal möglich war, wie sonst üblich. Vielmehr wurde die Produktion vom Ende her gedacht: Was für jeden einzelnen Schritt benötigt wird, bestimmt, wie viel im Schritt davor produziert wird. So „zieht“ jedes Element alle nötigen Komponenten aus den vorhergehenden Schritten. Damit stehen z.B. nicht 20 Motoren in der Fabrikhalle, wenn gerade nur zehn Fahrgestelle da sind, auf die sie montiert werden können.
In der modernen Produktion sind alle Produktionsschritte genau aufeinander abgestimmt – so dass es weder zu Staus noch zu Engpässen kommt.
Außerdem versucht man bei der Lean Production Abfall bzw. Verschwendung zu vermeiden. Und auch auf die Arbeiter wird großen Wert gelegt – sie sollen sich mit den Produkten identifizieren und Verbesserungsvorschläge machen. Auch die ständige Verbesserung gehört zu den Kernideen von Lean.
Prozesse möglichst schlank halten
Der Begriff „lean“ machte davon ausgehend eine noch größere Karriere als „agile“. Heutzutage ist alles lean – von der Cuisine bis hin zum Enterprise.
Seit ein paar Jahren ist Lean Management schwer in Mode. Insbesondere das Lean Start-up hat dazu beigetragen. Die Idee dazu ist entstanden, als ums Jahr 2000 die Dotcom-Blase platzte und ungezählte Start-ups pleitegingen. Mit einem Lean Start-up wird versucht, alle Prozesse möglichst schlank zu halten, Kunden/Nutzer frühzeitig in die Entwicklung einzubeziehen und deren Feedback zur Verbesserung zu nutzen.
Ganz wichtig in diesem Zusammenhang ist das angestrebte Minimum Viable Product (MVP), also das minimal überlebensfähige Produkt. Das ist die absolute Grundversion eines Produkts, die mit minimalem Aufwand hergestellt werden kann und sich verkaufen lässt. Davon ausgehend kann das Produkt dann Schritt für Schritt weiterentwickelt werden.
Und was hat „lean“ jetzt mit „agile“ zu tun?
Das ist eine gute Frage. Denn gern werden „lean“ und „agile“ von Beratern, Journalisten und Entscheidern durcheinandergeworfen. Beides sind Ansätze, um Produkte schnell, gut und kostengünstig zu entwickeln. Aber direkt haben sie nichts miteinander zu tun. Du kannst agile Entwicklung machen in einer Organisation, die mit Lean Management nicht viel am Hut hat. Und umgekehrt wurde in Unternehmen, die Lean Production betrieben, jahrzehntelang nach dem Wasserfallmodell gearbeitet.
Wo wir aber dann doch große Gemeinsamkeiten von „lean“ und „agile“ sehen, ist bei der Idee der Kundenzentrierung. Beim Lean Start-up werden so schnell wie möglich Prototypen entwickelt und Stakeholdern sowie potenziellen Kunden/Nutzern gezeigt. Aus dem Feedback heraus wird das Produkt dann verbessert. In mehreren Iterationen kommt das Produkt dann so schnell wie möglich zur Marktreife. Das ähnelt dem agilen Prozessmodell von Scrum.
Beim Lean Start-up ist der Bauen-Messen-Lernen-Zyklus zentral.
Bild: Wikimedia
Lean UX in der Praxis
So, jetzt solltest du eine grobe Vorstellung von den wichtigsten Begriffen rund um „agile“ und „lean“ haben. Das ist unser Rüstzeug, um uns zum Schluss noch Lean UX vorzunehmen.
Lean UX ist eigentlich nichts fundamental Anderes als die UX, wie wir sie alle seit Langem kennen. Der Unterschied ist nur, dass du bei Lean UX weniger Wert auf Dokumente legst („Deliverables“ wie Berichte, Reviews etc.), sondern mehr auf gemeinsames Ausprobieren und vor allem auf Teamwork.
Bei Lean UX verbringst du weniger Zeit damit, entspannt ein paar Nutzertests zu machen und dann in Ruhe aufzuschreiben, welche Probleme du gefunden hast. Nutzertests machst du natürlich weiterhin, aber idealerweise ist das ganze Team als Beobachter dabei. Und direkt im Anschluss an jede Sitzung diskutiert ihr die Ergebnisse und findet vielleicht sogar schon Lösungsvorschläge.
Als Dokumentation reicht es dann, wenn du Fotos der Flipcharts machst, auf denen ihr die Beobachtungen und Ideen gesammelt habt. Kein ausführlicher Bericht ist mehr nötig, keine Highlight-Videos, keine Präsentation der Ergebnisse.
Im Lean UX gibt es die drei Phasen:
- Denken
- Machen
- Prüfen
Denken heißt, ihr überlegt, was das Problem ist. Was ihr dem Nutzer anbieten wollt. Was dessen Interesse an eurer Lösung sein könnte. Hier kommen die klassischen Methoden des User Research zum Einsatz.
Dann geht es ans Machen: Ihr baut so früh wie möglich Prototypen.
Und beim Prüfen seht ihr euch an, wie die Nutzer mit dem Prototypen umgehen.
Und damit beginnt es wieder von vorn: Ihr denkt drüber nach, was das Problem ist, was die Nutzer wollen und so weiter.
Wenn du jetzt das Gefühl hast, das klingt doch sehr nach Scrum, dann liegst du genau richtig. Auch hier arbeitet man in Zyklen, auch hier sollen Teams gemeinsam arbeiten, auch hier wird weniger Wert auf Dokumentation gelegt.
Deshalb ist Lean UX ein Weg, als UX-Experte erfolgreich in einem Scrum-Team zu arbeiten.
Aber du kannst auch dann Lean UX machen, wenn das Entwicklungsteam nicht mit agilen Methoden arbeitet.
Grundlage von Lean UX: Der Zyklus Denken – Machen – Prüfen.
Bild: Ruben Brinkman
Wann sind Lean & Agile in der Produktentwicklung sinnvoll?
Die kurze Antwort auf die Frage, wann Agile und Lean in der Produktentwicklung sinnvoll sind, ist: immer.
Die etwas ausführlichere Antwort ist: Je nach Unternehmen und Projekt kann es einfacher oder nicht ganz so einfach sein, agile Prozesse und/oder Lean UX einzuführen. Besonders bietet es sich an, wenn:
- Der Markt für das Produkt entweder noch unklar ist oder sich gerade im Umbruch befindet.
- Die Anforderungen an das Produkt noch nicht eindeutig sind.
- Du Zugriff auf potenzielle Kunden/Vertreter der Zielgruppe hast.
- Ihr noch nie ein vergleichbares Produkt entwickelt habt.
- Sich das Produkt Schritt für Schritt entwickeln und verbessern lässt. Wenn man also schon etwas damit anfangen kann, wenn es noch nicht 100 % fertig ist.
Lean & Agile – ein starkes Team für gutes UCD
Wenn du nutzerzentriertes Design (User Centered Design (UCD)) machen willst, dann geht das auch ohne agile Entwicklung und Lean UX. Aber deine Produkte werden sicher besser und die Arbeit macht allen Beteiligten mehr Spaß, wenn ihr agil und lean arbeitet.
Das Schöne an Lean UX finde ich persönlich den undogmatischen Ansatz. Hier gibt es kein festgelegtes Regelwerk, keinen Kanon, den du beachten musst. Du setzt die Methoden ein, die dir sinnvoll erscheinen. Du probierst auch bei der Produktentwicklung selbst aus, prüfst, was wie gut funktioniert und änderst deine Methoden, um noch besser zu werden.
Meine ganz persönlichen Tipps, um dein UX-Vorgehen schlanker („lean“) zu machen, sind diese:
- Bringe alle Teammitglieder so früh wie möglich zusammen. Nehmt euch an mindestens drei aufeinanderfolgenden Tagen jeweils sechs Stunden Zeit und schließt euch in einem Besprechungsraum ein.
- Erarbeitet hier gemeinsam an einem Tag Personas. Also plakative Darstellungen der zukünftigen Nutzer.
- Geht dann am zweiten Tag darauf ein, welche Probleme die Personas haben, die ihr mit eurem Produkt lösen wollt. Seht euch die Situationen genau an, in denen die Personas euer Produkt nutzen werden. Überlegt, ob es echte Probleme sind und ob sie tatsächlich bereit wären, für die Lösung etwas zu bezahlen.
- Am dritten Tag stellt ihr die Nutzungssituation nach und baut Prototypen. Lego, Knete, Holz oder einfach Schere, Stift und Papier sind die Werkzeuge, mit denen ihr schnell und unkompliziert ganz einfache Prototypen herstellen könnt.
- Mit den Prototypen kannst du dann gleich ans Testen gehen. Lege die Prototypen echten Nutzern vor und lass sie damit umgehen. Am besten ist, wenn möglichst viele Teamkollegen den Test beobachten. Dann erfahren sie alle direkt, wo Probleme liegen und was gut funktioniert.
- Mit den Erkenntnissen geht es in die nächste Runde. Also am besten wieder gemeinsam Prototypen bauen. Das Ergebnis ist dann kein Dokument, sondern wieder ein Prototyp. Damit ersparst du dir eine schriftliche Dokumentation. Lean eben.
Du siehst: Der zentrale Punkt dabei ist, dass du nicht am Anfang einmal ein geniales Konzept entwickelst, sondern dieses Stück für Stück im Laufe des Projekts entsteht.
Diese Grafik zeigt, wie Design Thinking, Lean Start-up & Agile im Projekt zusammenkommen können.
Bild: kisspng
Es geht ohne Lean & Agile, nur geht es besser mit
Agile Entwicklung ist aus der Programmierung nicht mehr wegzudenken. Als UX-Experte kannst du von der Offenheit und Flexibilität der Entwicklungsarbeit profitieren. Versuche, dich während der Sprints einzubringen mit deiner Expertise.
Und führe einen Sprint 0 ein, um die Produktentwicklung auf ein solides Fundament stellen zu können. Hier ist der Platz für User Research, auf das auch in agilen Projekten nicht verzichtet werden kann.
Lean UX hat den Vorteil, dass du damit ganz flexibel bist in der Wahl deines Vorgehens. Du kannst aus den Bereichen User Research und Ideenfindung das einbringen, was für das jeweilige Projekt im jeweiligen Team am meisten Erfolg verspricht. Damit kannst du bei Kolleginnen und Kolleginnen das Verständnis für diese Ansätze verbessern.
Nur nennt nicht einfach alles, was modern und schnell sein soll, agile. Oder lean. Oder beides. Es geht um mehr als modische Begriffe, es geht darum, bessere Produkte zu entwickeln und entspannter zu arbeiten. Dabei muss man weder agile noch lean vorgehen – aber es hilft ungemein.
Suche dir einfach das Beste aus den vielen vorhandenen Methoden heraus und passe es für deine ganz persönlichen Projekte an. Damit hast du schon die Grundidee von Lean UX angewandt und kannst in allen Teams großartige Produkte entwickeln – ob nach agilem Vorgehen oder nicht.