Design Thinking vs. Lean vs. Agile vs. Design Sprint: was wann passt

Wählen Sie Design Thinking, wenn Sie das Problem noch nicht verstehen. Wählen Sie Lean Startup, wenn Sie eine Idee haben und günstig herausfinden müssen, ob sie funktioniert. Wählen Sie Agile, wenn Sie wissen, was gebaut werden soll, und es in funktionierenden Teilen liefern müssen. Wählen Sie einen Design Sprint, wenn ein klares, wichtiges Problem innerhalb einer Woche eine getestete Antwort braucht. Sie sind keine Konkurrenten: Jeder Ansatz beantwortet eine andere Frage, und die meisten echten Projekte nutzen mehrere nacheinander.

Die Verwirrung entsteht, weil alle vier über Nutzer, Iteration und Lernen sprechen. Der Unterschied liegt darin, was jeder Ansatz voraussetzt, dass Sie zu Beginn bereits wissen. Zur übergeordneten Frage, welche einzelne Methode Sie einsetzen sollten, lesen Sie Welche Innovationsmethode passt?.

Woher die Ansätze kommen

Ein kurzer Blick in die Geschichte hilft, denn jeder Ansatz trägt noch das Problem in sich, für das er gebaut wurde.

• Design Thinking ist aus der Designpraxis entstanden und wurde von der Designagentur IDEO und der Stanford d.school (dem Hasso Plattner Institute of Design, gegründet 2005) als allgemeiner Problemlösungsansatz bekannt gemacht. Der Double Diamond des britischen Design Council, 2003 entwickelt, beschreibt eine ähnliche Form. Gebaut wurde es für Probleme, bei denen schon das Bedürfnis unklar ist.
• Lean Startup hat Eric Ries in seinem Buch The Lean Startup von 2011 dargelegt, gestützt auf Steve Blanks Customer Development und auf Lean Manufacturing. Gebaut wurde es für Gründerinnen und Gründer, die Gefahr laufen, Jahre an etwas zu bauen, das niemand will.
• Agile geht auf das Manifest für Agile Softwareentwicklung zurück, das 17 Softwarepraktiker im Februar 2001 in Snowbird, Utah, verfasst haben. Scrum, entwickelt von Ken Schwaber und Jeff Sutherland, ist das bekannteste Framework. Gebaut wurde es für Softwareprojekte, die an langen, starren Plänen scheiterten.
• Der Design Sprint wurde von Jake Knapp bei Google und Google Ventures entwickelt und 2016 im Buch Sprint von Knapp, John Zeratsky und Braden Kowitz beschrieben. Gebaut wurde er, um ein Team in fünf Tagen von einer schwierigen Frage zu einem getesteten Prototyp zu bringen.

Im direkten Vergleich

Wann was passt

Design Thinking, wenn das Problem unklar ist

Verschiedene Menschen beschreiben Ihnen das Problem auf verschiedene Weise. Es gibt Beschwerden, aber niemand kann sagen, was sie verursacht. Ein neuer Service wird für eine Gruppe gebraucht, die Sie nie untersucht haben. In solchen Fällen überspringt, wer mit Ideen oder Umsetzung beginnt, die wertvollste Arbeit. Beginnen Sie mit Stakeholder-Interviews und schließen Sie die Problemdefinition mit einem Point-of-View-Statement und Wie-könnten-wir-Fragen ab. Den vollständigen Prozess finden Sie in Design Thinking Schritt für Schritt.

Nutzen Sie es nicht, wenn das Problem gut verstanden ist und die Organisation Umsetzung braucht. Eine Discovery-Phase zu einem Problem, das alle schon verstehen, testet die Geduld, nicht die Ideen.

Lean Startup, wenn Sie eine Idee haben und das Risiko ist, dass sie niemand will

Sie haben ein Konzept, einen Sponsor und etwas Begeisterung, aber keine Evidenz, dass Menschen es nutzen, dafür bezahlen oder ihr Verhalten dafür ändern werden. Lean-Denken verlangt, die riskanteste Annahme mit Assumption Mapping zu identifizieren, einen Hypothesentest zu formulieren und das kleinste Experiment durchzuführen, das Sie widerlegen könnte, etwa einen Concierge-Test. Mehr dazu in Wie Sie eine Idee testen, bevor Sie sie bauen.

Schwächer ist der Ansatz, wenn das Problem selbst unklar ist (dann testen Sie Antworten auf die falsche Frage), und bei Leistungen, bei denen Sie nicht ohne Weiteres ethisch oder rechtlich vertretbare Experimente mit der Öffentlichkeit durchführen können. In der Verwaltung brauchen viele Experimente ein anderes Gespräch über Einwilligung und Risiko als in einem Startup.

Agile, wenn Sie wissen, was gebaut werden soll

Das Konzept ist validiert, und die Arbeit ist hauptsächlich Umsetzung: das System, den Prozess, den Service bauen. Agile zerlegt die Arbeit in kleine Inkremente, formuliert als User Stories, liefert funktionierende Teile in kurzen Zyklen und justiert über regelmäßige Retrospektiven nach.

Agile sagt Ihnen nicht, was Sie bauen sollen. Teams, die es für Discovery einsetzen, liefern oft schnell Features, die niemand gebraucht hat. Es passt auch schlecht, wo Verträge, Vergabe oder Regulierung den Umfang vorab festlegen, es sei denn, diese sind so aufgesetzt, dass Änderungen möglich sind.

Design Sprint, wenn eine wichtige Frage diese Woche eine Antwort braucht

Ein Design Sprint passt, wenn die Herausforderung definiert ist, viel genug auf dem Spiel steht, um fünf Tage der Zeit einer entscheidenden Person zu rechtfertigen, und das Team zwischen Optionen feststeckt. Der klassische Ablauf: Montag das Problem kartieren und ein Ziel wählen; Dienstag einzeln Lösungen skizzieren; Mittwoch entscheiden und ein Storyboard erstellen; Donnerstag einen realistischen Prototyp bauen; Freitag mit fünf Nutzern testen.

Er passt schlecht, wenn niemand die Nutzer erforscht hat (dann stützt sich der Sprint auf Annahmen), wenn die entscheidende Person nicht teilnehmen kann oder wenn das Problem zu groß ist, um es an einem Tag zu prototypisieren.

Kombinieren: die übliche Abfolge

Die Ansätze funktionieren am besten in einer Reihenfolge, die der Unsicherheit folgt.

1. Design Thinking, um zu verstehen und das Problem zu definieren. Forschung und eine freigegebene Problemstellung.
2. Ein Design Sprint, um zusammenzuführen. Nutzen Sie die Forschung, um den Montag des Sprints schneller und fundierter zu machen, und gehen Sie mit einem getesteten Konzept heraus.
3. Lean-Experimente, um Risiken abzubauen. Testen Sie die Annahmen, die der Sprint nicht geklärt hat, etwa ob Menschen den Service auch nach der ersten Woche weiter nutzen.
4. Agile, um zu liefern. Bauen und veröffentlichen Sie in Inkrementen und testen Sie dabei weiter mit Nutzern.

Nicht jedes Projekt braucht alle vier. Eine kleine interne Prozessverbesserung braucht vielleicht eine Woche Discovery und dann die Umsetzung. Ein neues digitales Produkt kann direkt in einen Sprint gehen, wenn die Forschung bereits vorliegt. Die Faustregel: Ermitteln Sie Ihre größte Unbekannte und nutzen Sie den Ansatz, der für genau diese Unbekannte gebaut wurde.

Ein Praxisbeispiel

Illustrativ. Ein nationaler Postdienstleister in einem mittelgroßen europäischen Land möchte einen Service für kleine Onlinehändler anbieten.

Design Thinking (sechs Wochen). Das Team interviewt zwanzig Händlerinnen und Händler und beobachtet mehrere beim Verpacken von Bestellungen. Erwartet wurde das Problem Portokosten. Das tatsächliche: Die Händler verlieren jede Woche Stunden mit Retouren, weil Käufer Etiketten falsch ausdrucken und Pakete ohne Zuordnung zurückkommen. Die Problemstellung wird freigegeben: „Wie könnten wir Retouren für Händler mit weniger als fünfzig Bestellungen pro Woche mühelos machen?“

Design Sprint (fünf Tage). Mit dem Leiter des Paketgeschäfts am Montag und Mittwoch im Raum skizziert, wählt und prototypisiert das Team einen Retourencode, den der Käufer am Schalter vorzeigt, ganz ohne Ausdrucken. Fünf Händler testen ihn am Freitag. Vier wollen ihn, und alle fünf fragen, ob er mit ihrem Marktplatz funktioniert.

Lean-Experiment (vier Wochen). Die riskanteste verbleibende Annahme ist, dass das Schalterpersonal die Codes bearbeiten kann, ohne die Warteschlange zu verlangsamen. Das Team führt in drei Filialen eine Concierge-Version durch, bei der das Personal die Codes manuell anhand einer ausgedruckten Liste abwickelt. Die Wartezeiten bleiben stabil.

Agile Umsetzung (fortlaufend). Ein Umsetzungsteam baut das echte System in Zwei-Wochen-Sprints, beginnend mit einer Marktplatz-Integration und dem Scan-Schritt am Schalter, und testet jedes Release mit Händlern.

Jeder Ansatz hat die Aufgabe erfüllt, für die er gebaut wurde. Ein Start mit Agile hätte ein schnelles Porto-Rabatt-Tool hervorgebracht. Ein Start mit einem Sprint hätte das Retourenproblem komplett übersehen.

Was Sie tun und was Sie lassen sollten

Tun

• Benennen Sie zuerst Ihre größte Unbekannte und wählen Sie dann den Ansatz, der dafür gebaut ist.
• Speisen Sie Forschung in Design Sprints ein. Ein Sprint auf Grundlage echter Nutzererkenntnisse ist viel stärker als einer, der auf Vermutungen beruht.
• Testen Sie weiter mit Nutzern, sobald die agile Umsetzung beginnt.
• Vereinbaren Sie vorab, wem die Übergabe zwischen den Phasen gehört, besonders vom Sprint in die Umsetzung.

Lassen

• Behandeln Sie die vier nicht als konkurrierende Marken und fragen Sie nicht, welche „die beste“ ist. Das ist, als würde man fragen, ob eine Landkarte einen Hammer schlägt.
• Nutzen Sie Agile nicht für Discovery. Kurze Lieferzyklen ersetzen nicht, das Problem zu verstehen.
• Führen Sie keinen Design Sprint ohne die entscheidende Person durch. Sie bekommen einen guten Prototyp und keine Entscheidung.
• Nennen Sie nicht jeden Workshop einen Design Sprint. Fünf Tage mit der festgelegten Struktur sind das eine; eine zweistündige Ideenrunde ist etwas anderes.
• Lassen Sie nicht jeden Ansatz in einer anderen Abteilung mit eigenem Vokabular leben. An den Übergaben geht das Gelernte verloren.

Häufige Fragen

Ist ein Design Sprint dasselbe wie Design Thinking? Nein. Ein Design Sprint ist ein festgelegter Fünf-Tage-Prozess, der mehrere Design-Thinking-Werkzeuge nutzt, um eine definierte Frage zu beantworten. Design Thinking ist der breitere Ansatz, und seine Discovery-Arbeit kommt in der Regel vor einem Sprint.

Können Design Thinking und Agile zusammenarbeiten? Ja, und sie sollten es. Design Thinking klärt, was gebaut werden soll und für wen; Agile baut es in Inkrementen. Das übliche Muster ist eine Discovery-Phase, gefolgt von agiler Umsetzung mit einem regelmäßigen Rhythmus von Nutzertests.

Was ist besser für Projekte der öffentlichen Verwaltung? Das hängt von der Unbekannten ab. Design Thinking eignet sich für Leistungen, bei denen die Bedürfnisse der Bürgerinnen und Bürger unklar sind; Agile für die digitale Umsetzung, sobald die Bedürfnisse klar sind; Lean-Experimente brauchen besondere Sorgfalt bei Einwilligung und Risiko, wenn die Öffentlichkeit beteiligt ist. Viele Standards für digitale Verwaltungsleistungen verbinden Discovery mit agiler Umsetzung.

Wie es weitergeht

Für Discovery beginnen Sie mit Stakeholder-Interviews. Um eine Idee abzusichern, nutzen Sie Assumption Mapping. Für den Prototyp-Tag des Sprints siehe Papierprototyp, und für die Umsetzung User Stories. Alle Methodenleitfäden finden Sie in der Übersicht der Leitfäden.