Agile Sprints vs. Design Sprints

Wie und wann diese leistungsstarken Frameworks verbunden werden müssen, um neue Produkte zu erstellen oder bestehende zu überdenken.

Hintergrund

In den 2000er Jahren gewöhnte sich die Geschäftswelt an Produktentwicklungsbegriffe wie Agile, Scrum, Lean und MVP.

Es fand eine Verschiebung statt, die viele von uns von den vom Industriezeitalter inspirierten Wasserfallprozessen wegführte, in denen alles im Voraus dokumentiert und dann durch Bühnentore geschoben wurde, bis die Produkte endlich einsatzbereit waren. An die Stelle des Wasserfalls traten iterative Entwicklungsansätze wie Scrum, Kanban, XP (extreme Programmierung) und andere Variationen.

Diese Disziplinen wandten sich vom Ansatz des Silos mit Wasserfällen ab und ersetzten ihn durch schlanke, messbare Zyklen von Bauen, Testen und Versenden. Diese schnellen Zyklen, die in der Regel 1 bis 2 Wochen dauern, wurden treffend als „Sprints“ bezeichnet.

Produkt- und Projektmanager haben ihre Gantt-Diagramme anstelle von Sprint-Plänen verworfen, um ihre Produktentwicklungspläne zu organisieren. Dabei wurden priorisierte Funktionen aus dem Product Backlog in das Sprint-Backlog gezogen, durch einen Sprint geleitet und dann für die Produktion freigegeben.

Mit freundlicher Genehmigung von Agilebuddha.com

Und als sich die Führungskräfte von C-suite und Sales & Marketing an Sprints gewöhnten und lernten, die neueste Sprache ihrer Technologiegruppen zu sprechen, sprudelte 2015 ein neuer „Sprint“ in die Höhe - der Design Sprint.

Design Sprints, die dem Design Thinking Framework von IDEO nachempfunden sind, wurden ursprünglich von Jake Knapp bei Google entwickelt, um die erfolgreiche Einführung von Produkten wie Google Mail und Hangouts (jetzt Meet) zu koordinieren.

Im Laufe der Jahre und Hunderte von Sprints hat Jake den Prozess schließlich dahingehend verbessert, dass multidisziplinäre Teams 5 Tage lang Probleme im Zusammenhang mit dem Großunternehmen verstehen, entwickeln, prototypisieren und testen konnten, bevor sie mit der vollständigen Produktentwicklung begannen.

Nach unzähligen Erfolgsgeschichten schnappte sich GV Jake und entwarf Sprints, um sie (sowohl Jake als auch Sprints) ihren Portfolio-Unternehmen anzubieten. Jake und mehrere andere GV-Designpartner, die Sprints eingesetzt hatten, um Unternehmen wie Uber, Slack und Blue Bottle Coffee (unter anderem) zu helfen, veröffentlichten das Sprint-Buch am 8. März 2016. Es wurde schnell zu einem Bestseller der NY Times und des WSJ .

Seitdem haben Produktteams auf der ganzen Welt Design Sprints in ihr Toolkit aufgenommen, getestet und übernommen. Zweifellos haben Design-Sprints die Art und Weise verändert, wie Unternehmen aller Größen und Formen mit der Entwicklung neuer Produkte und Dienstleistungen umgehen.

Aber da ist noch etwas

Seit Design-Sprints Wellen schlagen, taucht immer wieder eine ganz bestimmte Frage auf. Wir hören es in fast allen Workshops, die wir anbieten, um Produktmanagern, Designern, Ingenieuren, Forschern und Führungskräften Design-Sprints beizubringen.

Und deshalb hoffe ich, heute etwas Licht in die Beziehung zwischen Design-Sprints und agilen Entwicklungs-Sprints zu bringen, sowohl für neu erstellte Produkte als auch für die Neuerstellung oder den Relaunch bestehender Produkte.

Lassen Sie mich zunächst ein Bild von allen Teilen des digitalen Produktentwicklungsprozesses zeichnen.

Software-fähige Innovation

Bei New Haircut denken wir über den Prozess der Erstellung digitaler Lösungen zur Lösung großer Probleme in 8 eng miteinander verknüpften Aktivitäten nach.

Während das Bild sequentiell aussieht, ist es wichtig zu beachten, dass die Produktentwicklung niemals linear ist.
  • Geschäftsausrichtung: Entscheiden, an Problemen zu arbeiten, die mit der Strategie, Vision und den Ressourcen des Unternehmens in Einklang stehen
  • User Research: Erfahren Sie mehr über den Markt, die Benutzer und den Wettbewerb, die mit diesen Problemen zusammenhängen
  • Design Thinking (über Design Sprints): Aufbau eines Verständnisses des Problems und Validierung prototypischer Lösungen mit potenziellen Kunden
  • MVP-Planung: Erstellen Sie ein vollständiges Bild Ihrer Lösung und legen Sie fest, welches wertvolle Produkt (MVP) Sie im Rahmen einer Produkt-Roadmap auf den Markt bringen möchten
  • UX Design: Aufbau der Informationsarchitektur, der Interaktionen und des Flusses der menschenzentrierten Erlebnisse, die Sie in Ihrer Lösung anbieten
  • Visuelles Design: Geben Sie Ihrer Lösung einen Stil, einen Ton und eine Benutzeroberfläche (falls zutreffend).
  • Logistik: Zeichnen Sie die Systeminfrastruktur und Anwendungsarchitektur Ihrer Lösung auf
  • Agile Entwicklung: Machen Sie den Kern Ihrer Softwarelösung aus und bringen Sie sie auf den Markt.

Hinweis: Viele Teams bündeln UX und / oder visuelles Design in einer agilen Entwicklung. Wir haben festgestellt, dass dies für einfachere Anwendungen und kleine Funktionsverbesserungen am besten geeignet ist. Bei der Entwicklung digitaler Unternehmensprodukte haben wir festgestellt, dass es effektiver und effizienter ist, diese geringfügig voneinander zu trennen, obwohl Teams häufig zeitgleich arbeiten.

Sprints für neue Produkte

Beim ersten Mal durch einen solchen Ansatz - wenn Sie zum ersten Mal ein neues Produkt entwickeln - treten Design-Sprints vor agilen Entwicklungs-Sprints auf.

Dies ist sinnvoll. Bevor Sie mit dem Entwerfen und Codieren beginnen, möchten Sie zunächst einen Überblick über das Problem und den Benutzer erhalten und anschließend Lösungen mit Einwegprototypen testen. Prototypen sind nicht nur billiger und schneller, das Team investiert auch weniger emotional in einen Prototypen als in schön gestaltete Bildschirme und funktionierenden Code.

Wie?

Wenn Sie einen Design-Sprint beenden, verfügen Sie über einen Prototyp, der mit ~ 5 Zielbenutzern getestet wurde. Wie überbrücken wir dann den Prototyp zum funktionsfähigen Produkt?

In einer Produkt-Roadmap wird der spezifische Fokus innerhalb Ihres Design-Sprint-Prototyps erläutert, um die verbleibenden priorisierten Funktionen / Bildschirme / Benutzerabläufe zu präzisieren. Diese Prioritäten werden zu Einträgen in Ihrem Produkt-Backlog, die dann in Ihre agilen Entwicklungs-Sprints eingespeist werden können.

Code-Sprints

Wir stellen immer sicher, dass unsere Design-Sprints von einem technischen Experten ausgeführt werden. Wir stellten jedoch fest, dass dieser einzelne Ingenieur seine Konstruktionsinformationen an sein Team aus Architekten, Programmierern und Testern weiterleitete - es gab noch eine Menge Fragen, bevor sie sich vertiefen konnten.

  • Welche Technologie kann am besten genutzt werden?
  • Gibt es bestehende Lösungen, die wir integrieren können?
  • Wo sollen wir uns zuerst konzentrieren?

Also haben wir einen Code Sprint entwickelt (ja, wir haben dem Mix noch einen weiteren Begriff hinzugefügt… sorry?).

Neuer Haircut-Code-Sprint

In einem Code Sprint verbringen Technologieteams 4 bis 5 Tage, um:

  • Verstehen Sie alle zuvor zusammengestellten Informationen
  • Stimmen Sie über die 2-3 größten technologischen Herausforderungen ab, die sie bewältigen müssen
  • Divergieren Sie, um konkurrierende Prototypen für jede Herausforderung zu erforschen und zu bauen
  • Testen Sie die Prototypen, die letztendlich helfen, über die siegreiche (n) Implementierung (en) zu entscheiden.

Wir haben Code-Sprints so modelliert, dass sie die gleichen intensiven Fokus-, Dauer- und Divergent-Konvergent-Techniken wie ein Design-Sprint verwenden. Anschließend konnten unsere Tech-Teams nicht nur die Fragen „Was bauen wir?“ Und „Wie bauen wir es?“ Beantworten, sondern auch eine grundlegende Schicht aus Infrastruktur, Architektur und Code erstellen, auf der sie innerhalb ihrer Agile aufbauen können Entwicklungssprints.

Erwartete Verbesserungen

Bei der Einführung von agilen Entwicklungs-Sprints in Form von Design- und Code-Sprints haben wir einige wesentliche Verbesserungen sowohl bei den Produkten, die wir unseren Kundenunternehmen anbieten, als auch bei den Methoden, mit denen wir sie starten, festgestellt:

  • Erholen Sie sich Monate und Jahre lang von vergeudeten Anstrengungen, um Probleme zu lösen, die Menschen nicht interessieren
  • Ermöglichen Sie technischen Organisationen die effektive Zusammenarbeit mit anderen im Produktentwicklungsprozess
  • (von alt nach oben) Befähigen Sie Rollen außerhalb von Produkt und Technologie, einen notwendigen und willkommenen Platz am Lösungstisch einzunehmen
  • Geben Sie den Entwicklungsteams die einfühlsame Perspektive und Stimme des Benutzers, die sie normalerweise vermissen

Sprints für bestehende Produkte

Aber was ist, wenn Sie an einem vorhandenen Produkt arbeiten?

Ein Fehler, den viele Teams machen, wenn sie Design-Sprints zum ersten Mal einsetzen, ist, sie zu überbeanspruchen. Sie starten Design-Sprints für nahezu jedes Feature, das sie einführen möchten. Hinzufügen eines Formulars zu einer Seite? "Lassen Sie uns einen Sprint starten." Erstellen Sie die iOS-Version unserer Android-App? "Sprint!" Das ist übertrieben.

Ein Design-Sprint eignet sich am besten für ein Problem, das auf eine wichtige Geschäftsgelegenheit oder -herausforderung zurückzuführen ist. Wenn Ihr Unternehmen beispielsweise beschließt, Ihr Produkt einem völlig neuen Kundensegment anzubieten, ist dies eine wichtige Entscheidung, die über einen Design-Sprint weitergeleitet werden sollte.

Wie?

Eine vorhandene Lösung kann auf verschiedene Arten zu Einschränkungen führen:

  1. Es zwingt uns in den Lösungsmodus, bevor wir das Problem vollständig verstehen
  2. Es beeinflusst die Lösungen, die wir entwickeln
  3. (wenn wir in eine vorhandene Lösung einbauen müssen) Dadurch werden unsere Lösungen auf die Grenzen dieser Lösung beschränkt. Dies ist besonders schwierig, wenn diese Lösungen außerhalb unserer Kontrolle liegen. z.B. Plattformen / Daten / Zugang Dritter

Auf der anderen Seite bietet uns eine vorhandene Lösung auch Benchmarks, auf die neue Produkte keinen Zugriff haben.

Wenn Sie zum obigen Diagramm "Neuer Haarschnitt" zurückblättern, sehen Sie, dass die Problemvalidierung für einen Konstruktionssprint (Lösungsvalidierung) von entscheidender Bedeutung ist. Dies geschieht in der Regel in Form von ethnografischen Untersuchungen, Umfragen und Prototypen aus Papier (auch bekannt als Superleichtbau). Wenn jedoch zuvor vorhandene Lösungen abgerufen werden können, erhalten Sie eine zusätzliche Datenquelle.

Der Trick bei der Nutzung vorhandener Lösungsdaten besteht darin, die Erkenntnisse ohne Umsetzungsverzerrung herauszuholen. Mit anderen Worten handelt es sich bei den gesuchten Daten eher um die Muster (gut oder schlecht), die auf dem Problem basieren, das die vorhandene Lösung zu lösen versucht.

Wie diese Lösung derzeit implementiert ist, kann sicherlich festgestellt werden, sie sollte jedoch keinen großen Einfluss auf einen bevorstehenden Design-Sprint haben, der neue Möglichkeiten entdecken soll. Denken Sie daran, der Vorteil eines Design-Sprints besteht darin, dass Sie mit völlig neuen, interessanten und praktikablen Lösungen die Möglichkeit haben, große Träume zu verwirklichen.

Aufgrund dieser Vorliebe für Vorgänger bedeutet dies häufig, dass Sie über die Verwendung von Teammitgliedern aus früheren Inkarnationen in Lösungen der nächsten Generation sehr sorgfältig nachdenken möchten. Was gut funktioniert, ist, frühere Teammitglieder am Montag der Sprintwoche als externe Experten einzusetzen.

Leistungen

  • Nutzen Sie wichtige Erkenntnisse, auf die neue Produkte keinen Zugriff haben
  • Neue Lösungen können aus vorhandenen Lösungen ausgeliehen werden, um sie zu replizieren, oder ganz neue Erfahrungen sammeln

Und wie sieht es aus, wenn ein bestehendes Produkt einen Design-Sprint setzt, bevor es in eine agile Entwicklung übergeht?

Packen Sie agile Sprints und Design-Sprints ein

Produktentwicklungsteams sind ständig unter Druck, um bessere Produkte in kürzerer Zeit und mit geringerem Budget auf den Markt zu bringen. Die Zusammenstellung einer Kadenz, die die Vorteile von Design-Sprints, Code-Sprints und agilen Entwicklungs-Sprints nutzt, hat es uns ermöglicht, dies für unsere Kunden zu tun - ich hoffe, sie bietet Ihrer Organisation die gleichen Möglichkeiten.