Design Sprint remote: Wie Covid-19 neue Wege der Product Discovery und Delivery ermöglicht
Design Sprints ermöglichen cross-funktionalen Teams in nur fünf Tagen einen lauffähigen Prototypen zu bauen und mit Anwendern zu testen - gemeinsam in einem Raum und in ständiger Interaktion. Doch COVID-19 zwang uns, in kurzer Zeit vielfach erprobte Prozesse im Homeoffice neu zu denken. Ich möchte meine Erfahrungen aus der Sicht des Facilitators mit euch teilen, in der Hoffnung euch zur Durchführung eines Design Sprints im Remote-Modus zu ermutigen.
Zeiten ändern sich: Vor etlichen Jahren dachten und arbeiteten Softwareentwicklungsteams oftmals noch in ihrer Sphäre. Während das Anforderungsmanagement durch den PO lange vor der Umsetzung geschah, fanden User Tests erst spät danach Umsetzung statt. Die Produktverantwortung des Teams war lediglich auf den Schritt der eigentlichen Softwareentwicklung begrenzt. Das führte in der Vergangenheit oft dazu, dass Entwickler/innen Anforderungen nicht vollständig verstanden und folglich für die Ergebnisse ihrer Arbeit nur bedingt Verantwortung übernahmen. Die klassische Aufteilung von Ausdenken, Umsetzen und Auswerten hatte eine Zeit lang auch bei idealo seinen Platz. Doch so funktionierte es einfach nicht mehr.
Heute versuchen wir, ein ganzheitliches Anforderungs- und Produktverständnis zu schaffen. Hierfür braucht es einen Rahmen, in dem die vollständige Wertschöpfungskette der Produktentwicklung in den Blick genommen und rollenübergreifend ermöglicht wird. Mit dem „Design Sprint“ wird genau dieser Rahmen geschaffen. Beginnend von der Markt- und Problemanalyse werden Produktideen durch ein interdisziplinäres Team vom Papier in die greifbare Realität überführt. Dies geschieht in nie mehr als fünf Tagen. Der Design Sprint ersetzt damit einen sequenziellen Prozess, der zuvor noch etwa 8–12 Wochen in Anspruch nahm. Inspiriert durch verschiedene Design Thinking- und Agile-Produktentwicklungsmethoden wurde der Design Sprint in seiner heutigen Form von Jake Knapp erstmals bei Google im Jahr 2010 entwickelt und anschließend ständig verwendet und weiterentwickelt.
Wir bei idealo nutzen das Format des Design Sprints. In dem kurzen Zeitraum von maximal fünf Tagen erschaffen wir mit dem Endnutzer testbare Produktprototypen und fördern ein rollenübergreifendes „Wir“, das Identitätsbildung mit dem Produkt und Verantwortungsübernahme für den Prozess ermöglicht.
Als ich vor kurzem erneut eine Anfrage zur Durchführung eines Design Sprints von einem Produktentwicklungsteam erhielt, sagte ich sofort zu. Die Herausforderung, ein cross-funktionales Team in einen Raum zu “sperren”, es zu befähigen, ihr Produktziel eigenverantwortlich und über ihre klassischen, rollenspezifischen Grenzen hinweg zu verfolgen, war einfach zu verlockend.
Anders als bei “üblichen” Design Sprints verfolgte das cross-funktionale Team ein recht technisches Ziel. Es sollte die Frontend-Architektur des idealo-Direktkauf-Checkouts grundlegend überarbeitet werden. Der Product Owner (PO) des Teams war als Experte für das Produkt, den Markt und den Nutzer bei der Vorbereitung des Design Sprints mein Sparrings- und Ansprechpartner und brachte die fachlich-inhaltliche Perspektive für die Design Sprint-Gestaltung ein. Nach circa einwöchiger, sehr intensiver gemeinsamer Vorbereitung des Design Sprints änderte COVID-19 schlagartig eine Grundlage unserer Planung: Das Team wird nicht mehr länger in einem Raum zusammenarbeiten können. Die Zusammenarbeit ist als “mobile work” zu gestalten. Das stellte uns vor neue, bisher noch nicht bekannte Herausforderungen. Eine ganze Woche Design Sprint dezentral und aus dem “Homeoffice”? Das klang schier unmöglich. Denn der Design Sprint lebt von der räumlichen Nähe der Teilnehmer*innen, deren unmittelbaren Interaktionen und Rückmeldungen untereinander und vor allem von der Teamdynamik und -stimmung, die sich im Laufe der intensiven, gemeinsamen Tage entwickelt.
Wir wollten es herausfinden. Also kamen der PO und ich nochmals (virtuell) zusammen, um nun die einzelnen Design Sprint-Tage und -Schritte zu überdenken, umzuorganisieren und sie in kleinere Remote-Häppchen zu schneiden. Wie das dann genau aussah und wie das geklappt hat, möchte ich im Folgenden mit euch teilen.
Der Design Sprint “nach Buch” startet an einem Montag und dauert eine Arbeitswoche. Wir entschieden uns jedoch für ein viertägiges Vorgehen, da die Zielstellung technisch war und zunächst keine Tests mit Endnutzern erforderte. Begonnen haben wir an einem Dienstag und endeten am Freitag.
Die größte Schwierigkeit in Remote-Durchführung des Design Sprints lag an dem sinnvollen Aufeinanderbauen und -folgen der einzelnen Arbeitsschritte. Wir teilten die Design Sprint-Tage vorab in einzelne, aufeinanderaufbauende Arbeitsblöcke auf, die wir in jeweils separate Google-Meet-Termine gegossen haben. Diese wurde bereits vor Start des Design Sprints an alle Teilnehmer rausgeschickt.
Der Ablauf
Tag 1 — Map
Am ersten Tag (“Map”) des Design Sprints beschäftigt sich das Team hauptsächlich mit dem zu verfolgenden Ziel und Lösungskriterien. Hierbei schärfte es gemeinsam das Ziel für die gemeinsame Design Sprint-Woche, stellt Hypothesen auf und sammelt Fragen.
Im ersten Block erhielt das Team eine Einführung in den Design Sprint-Prozess. Diese beinhaltete die grobe Erläuterung des Ablaufs, des Zwecks und der Regeln des Design Sprints. An dieser Stelle war es sehr wichtig, allen klar zu machen, wie wir dazu im Remote-Modus uneingeschränkt zusammenarbeiten können, um so die Hemmschwelle einer aktiven Teilnahme so niedrig wie möglich zu halten. So sollten beispielsweise alle, wenn möglich, ihre Kamera anlassen, damit wir auch über die Ferne Mimik und Gestik als Feedback wahrnehmen können. Eine andere Regel war das Stummschalten des eigenen Mikros, sobald jemand anderes spricht, um so ein Hintergrundrauschen zu vermeiden. Eine weitere, sehr wichtige Regel lautete: Wenn jemand eine Frage stellt oder einen Lösungsvorschlag unterbreitet und keine aktive Rückmeldung von den Teilnehmern kommt, wird dies stets als Zustimmung verstanden.
Anschließend präsentierte der PO auf inhaltlicher Ebene den Grund und das primäre Ziel des Design Sprints und die damit verbundenen Akzeptanzkriterien.
Im letzten Teil des ersten Blocks bekam das Team die Möglichkeit, Gehörtes und Verstandenes zu reflektieren. Hierfür sammelten die Teilnehmer in einem zentralen Google-Doc ihre Sprint-Fragen, potenzielle Risiken oder Hypothesen zur Zielerreichung. Somit konnte jedes Teammitglied zeitgleich in das Dokument schreiben und sich von den Gedanken der anderen inspirieren lassen. Beendet wurde der erste Teil mit der Vorstellung der Ergebnisse.
Im zweiten Block folgte die gemeinsame Erstellung eines sogenannten “Architecture Diagram-Maps”. Hier gab der PO zu Beginn eine Einführung zum Vorgehen und gewünschten Ergebnis. Damit das Team eine gemeinsame Arbeits- und Diskussionsgrundlage hat, wurde seitens des POs ein Beispiel-Diagramm bereitgestellt. Wichtig war hier klarzustellen, dass dies lediglich als Arbeitshypothese zu verstehen ist. Das Team war dann an der Reihe, in reger Diskussion, das Bild zu vervollständigen und ein einheitliches Wissen zu gewinnen.
Nach diesem Block folgte die Mittagspause, die nicht erneut vor dem Rechner, sondern “offline” gestaltet wurde. Dies galt im Übrigen für alle Tage.
Nach der einstündigen Mittagspause begann der dritte Block, der die Experteninterviews (“Ask the Experts”) beinhaltete. Hier hatte das Team die Möglichkeit, zuvor vom PO ausgewählte und eingeladene Fachexperten zu interviewen. Die bereits gesammelten und besprochenen Sprint-Fragen und -Hypothesen dienten hier als Grundlage. Es wurden vier Fachexperten aus dem selben Fachbereich zu verschiedensten Aspekten der Zielerreichung befragt.
Im vierten und letzten Block des ersten Tages wurden die Notizen der Teammitglieder aus dem Interviews in sogenannte “How Might We”s (HMWs) umformuliert. Mit dieser Herangehensweise sollen aus neutralen oder problemorientierten Fakten potenzielle Lösungsansätze beschrieben werden. Auch diese wurden in einem zentralen Google-Doc gesammelt und anschließend vorgestellt. Daraufhin hatte jedes Teammitglied die Möglichkeit, die für sie wichtigsten zwei HMWs zu voten. Die höchstgevoteten HMWs wurden dann in einem gemeinsam geführten Austausch in der Architecture Diagram-Map verortet. Das Ziel war es hierbei, die HMWs da zu platzieren, wo sie inhaltlich in die Architecture Diagram-Map reinspielen. Dadurch wurde die Fragestellung schneller greif- und besprechbar. Die HMWs wurden in Form von Screenschot-Schnipseln in die Map reinkopiert.
In diesem letzten Block war das erste Mal der sogenannte “Decider” anwesend, der hier die Möglichkeit hatte, alle Ergebnisse des ersten, richtungsweisenden Tages zu sehen und darauf basierend einen finalen Teilaspekt der Architecture Diagram-Map auszuwählen. Dieser ausgewählte, finale Teilaspekt fungierte nun für die nächsten Tage als Fokusbereich für alle Teammitglieder.
Tag 2 — Sketch
Den zweiten Tag mit dem Titel “Sketch” teilten wir in fünf separate Blöcke auf. Im ersten Block fand ein halbstündiger Impulsvortrag eines teamexternen Fachexperten statt. Dieser Impulsvortrag sollte den Lösungsraum des Teams erweitern und als Inspirationsquelle für alle Teilnehmer dienen. Nach dem Vortrag hatten alle Teammitglieder die Möglichkeit, Verständnisfragen zu stellen und ins Gespräch mit dem Gast zu gehen.
Nach einer kleinen Pause folgte der zweite Block mit der Überschrift “Lightning Demos”. Ziel war es hier, dass jedes Teammitglied in einer Timebox von 60 Minuten und in Einzelarbeit Beispiel-Codes (aus u.a. öffentlichen GitHub-Quellen) raussucht, die in ihrer Beschaffenheit und Funktion als Vorbild für ihr Ziel-Produkt dienen können. Das soll weitere, potenziell unbekannte Lösungsmöglichkeiten eröffnen und für neue Ideen sorgen.
Im dritten Block wurden die recherchierten Code- und Lösungsbeispiele dem Team vorgestellt und die damit verbundenen Beweggründe und Potenziale erläutert. Die größte Herausforderung hierbei lag am zu bauenden Produkt und dessen Wesen, da dieses, wie bereits erwähnt, rein technischer Natur ist und nicht, wie oft im Design Thinking-Kontext bekannt, ein design-gesteuertes Frontend-Artefakt ist. Doch das Team hat dennoch viele wertvolle Beispiele im Netz entdecken und teilen können.
Nach der Lunchpause startete der vierte, größere Block. Hier war nun die Aufgabe für jeden, Architektur-Diagramm-Sketche zu bauen. In einer zweistündigen Timebox sollte jeder versuchen, eine Architekturlösung zu sketchen. Sie hatten hierbei die Möglichkeit ihren Diagramm-Sketch auf Papier zu malen, doch im Kontext der Remote-Zusammenarbeit war es wichtig, dass am Ende der zwei Stunden ein fertiger, präsentierbarer Lösungssketch steht. Da auch in diesem Schritt jedes Teammitglied alleine arbeitete, folgte der letzte und fünfte Block des Tages, in dem alle ihre Erfahrungen mit dem Sketchen teilten und Unklarheiten ausräumen konnten.
Tag 3 — Decide
Der dritte Tag trug die Überschrift “Decide” und damit lässt sich schnell erahnen, was hier passiert. Das Team sollte nach fünf Arbeitsblöcken eine gemeinsam getragene Entscheidung zu ihrem Lösungsmodell gefällt und ein gemeinsames Verständnis vom Vorgehen getroffen haben.
Im ersten Block wurden die am vorigen Tag erstellten und in Google-Präsentation geteilten Sketches von jedem Teammitglied vorgestellt und erläutert.
Im anschließenden Block sind wir tiefer gegangen und haben die Sketches genauer betrachtet. Hierbei war es die Aufgabe jedes Teammitglieds, durch alle Sketches durchzugehen und die interessantesten, für die Zielerreichung relevantesten Teilaspekte zu markieren. Diese wurden im Anschluss detaillierter besprochen. Nach den neu gewonnenen Ideen und Einblicken hatte jedes Teammitglied seinen Favoriten aus den markierten Teilaspekten gekennzeichnet. Diese fungierte zeitgleich als Entscheidungsvorlage für den Decider, der in diesem Block wieder vollständig dabei war. Nun war dieser an der Reihe seinen finalen Vote bzgl. der favorisierten Teilaspekte zu vergeben. Nachdem die finale Wahl auf ein Teilaspekt fiel, verabschiedeten wir uns in die Mittagspause.
Im dritten und vierten Block war der Arbeitsauftrag, die ausgewählten Teilaspekte in Absprache mit dem PO in umsetzbare, wertgenerierende Epics zu gießen. Diese wurden dann unter Betrachtung möglicher Risiken und Hindernisse hinsichtlich ihrer technischen Umsetzungsdauer geschätzt.
Im letzten und fünften Block wurde aus den Ergebnissen der vorigen zwei Blöcke ein sogenannter Migrationsplan erstellt. Die definierten Epics wurden in reger Diskussion und durch die Moderation des PO auf eine Timeline in Google-Präsentation gepackt und mit Release-Daten versehen. Mit dieser Planungshypothese sollen die nächsten Schritte im letzten Tag des Design Sprints gemacht werden.
Tag 4 — Prototype
Ziel des vierten und letzten Tags des Design Sprints war das Entwickeln eines lauffähigen, testbaren Prototyps. Begonnen haben wir hier mit einem kurzen Recap aller Tage und der Ergebnisse. Anschließend organisierten wir gemeinsam die anstehende Prototypentwicklung hinsichtlich ihrer Teilaspekte und der damit verbundenen Aufgabenverteilung. Das Team schnitt in Eigenregie den zu entwickelnen Prototypen in separate Entwicklungsblöcke und verteilte diese im Team.
Nachdem alle organisatorischen und inhaltliche Fragen beantwortet wurden, konnten die Teammitglieder anfangen, in Einzelarbeit und “offline” an ihren Prototypbausteinen zu arbeiten. Hierfür standen dem Team zwei zweistündige Blöcke zur Verfügung. Geteilt wurden die beiden Entwicklungsblöcke von einem zusätzlichen Q&A-Block, in der Unklarheiten besprochen wurden, die während der Prototypentwicklung entstanden sind.
Am Ende des Tages fand ein abschließender Review-Block statt, in dem die entwickelten Prototypbausteine, aber auch die Architecture-Diagram-Map sowie der Migrationsplan vorgestellt wurden. In diesem letzten Block waren auch der Decider und andere Fachbereichskollegen anwesend.
Abgeschlossen wurde der Tag sowie der Design Sprint mit einer finalen Feedbackrunde zu den Ergebnissen, zur Zusammenarbeit und zur Moderation.
Meine Learnings & Erkenntnisse
Rückblickend kann konstatiert werden, dass ein umfangreicher, intensiver Design Sprint auch im Remote-Modus und dezentral möglich ist. Wir haben in nur vier Arbeitstagen unser abgestecktes Ziel erfolgreich und zufriedenstellend erreicht. Aber auch erlebt zu haben, wie das Team im Sinne der agilen Produktentwicklung die volle Verantwortung für das Produkt und den Prozess übernommen hat, stimmt mich und den Auftraggeber mehr als positiv.
Die genutzten Tools müssen hierbei weder teuer noch technisch umfangreich sein. Gerade die altbekannten, bereits etablierten Google-Apps haben sich durchweg bewährt. Eine primäre Google-Präsentation mit vorbereiteten Arbeitsbausteinen als roter Faden für den Ablauf und die methodischen Schritte hat für viel Struktur und Transparenz gesorgt. Für das Erarbeiten von Sprint-Fragen, HMWs und die Lightning Demos haben Google-Docs ihren Dienst sehr erfolgreich getan. Für die Erstellung der Sketches und der Prototypen gab es keine Tool-Vorgabe. Wichtig war hier nur, dass jeder bei der Ergebnisvorstellung seinen Bildschirm teilt und die Ergebnisse in die primäre Präsentation packt.
Klar, der Design Sprint lebt von der persönlichen Interaktion und dem zwischenmenschlichen Miteinander. Das erweist sich logischerweise als schwierig, wenn jeder zu Hause vor seinem Rechner sitzt. Daher war es sehr wertvoll für die Teamdynamik, dass die Kameras der Teilnehmer stets online waren, um so eine gewisse Rückmeldung zu bekommen und Dynamik zu entwickeln. Wichtig war hier, unermüdlich an die oben bereits erwähnten Regeln der Remote-Zusammenarbeit und auch die des Design Sprints zu erinnern: “Es ist kein Meister vom Himmel gefallen!”, “Es gibt kein richtig und falsch.”, “Es geht nicht um ein formvollendetes Ergebnis, sondern um inspect & adapt”, “Mut, Offenheit und Respekt im Miteinander” sind einige davon.
Vier Tage am Stück, von morgen bis abends vor dem Rechner zu sitzen ist tatsächlich eine ganz andere körperliche wie geistige Anstrengung als die Arbeit vor Ort im Office. Die eingebauten Pausen zwischen den einzelnen Blöcken wirkten daher sehr vitalisierend und energiespendend. Verbunden damit haben wir uns in der Vorbereitung dazu entschlossen, die Lunch-Blöcke nicht als Hangout-Meet-Block anzubieten und betonten mehrmals, die einstündige Mittagspause zu nutzen, den Rechner zu verlassen und in Ruhe zu lunchen.
Im Sinne des Design Sprints nach Jake Knapp, war es fundamental, dass die einzelnen Schritte bzw. Blöcke nicht im vornherein bekannt waren. Um zu gewährleisten, dass die Design Sprint-Teilnehmer die Aufgaben unbefangen und neutral angehen können, wiesen die Termineinladungen keinerlei inhaltliche Informationen vor. Wenn der genaue Ablauf und die methodischen Schritte bereits zuvor durch beschriebene Einladungsblöcke bekannt wären, hätte das im Vorab, der Erfahrung nach, für große Unsicherheit und Ablenkung gesorgt. Daher war es umso wichtiger, genug Raum und Zeit für das Einführen und Erläutern der Aufgaben und Methoden einzuplanen und hierfür bereits vorbereitete Beispiele mitzubringen. Aber auch um gemeinsam wiederholt die erarbeiteten Artefakte (Sprint-Fragen, HMWs, Constraints, Akzeptanzkriterien usw.) anzuschauen und an das Sprint-Ziel zu erinnern.
Bestimmt ist aufgefallen, dass viele der Schritte, die wir im Design Sprint gemacht haben, stark vom Buch abweichen. Meine Erfahrung hat mir gezeigt, gerade in Zeiten des gezwungenen mobile works, dass die bedarfsgerechte Adaption und Anpassung des Frameworks sehr hilfreich für das Gesamtgelingen des Design Sprints ist. Ohne dabei den Geist des Design Sprints zu beeinträchtigen, sollten notwendige Anpassungen hinsichtlich der Methoden und deren Ablauf in Absprache mit dem Auftraggeber (hier bspw. der PO) gemacht werden. Dadurch kann gewährleistet werden, dass Erwartungen abgeglichen und Verantwortlichkeiten in der Durchführung frühzeitig delegiert sind.
Verbunden damit hat sich die enge Zusammenarbeit in der Vorbereitung und Planung des Design Sprints mit dem Auftraggeber sehr bewährt. Als fachlicher Experte ist er stärker in den Teamkontext involviert und kann so wunderbar als Sparringspartner wirken. So war es auch möglich, in der Moderation stets eine fachliche Perspektive in die Erläuterung der einzelnen Schritte seitens des POs einzubauen.
Was uns Schwierigkeiten machte, war das Briefing der Gäste. Die Fachexperten im Rahmen der Interviews, aber auch der Decider, der eine tragende Rolle im Design Sprint einnimmt, haben in ihrer Rollenausübung und Teilnahme eine gewisse Unsicherheit verspürt. Hier hätte es vor der Durchführung ein detaillierteres Briefing zum Prozess, ihrer Rolle und dessen Pflichten geben müssen.
Als wir die Entscheidung getroffen haben, den Design Sprint vollständig remote zu gestalten, musste ich erstmal schlucken. Denn schon allein die Erfahrung einen Design Sprint gemeinsam in einem Raum zu veranstalten ist herausfordernd und umfangreich genug. Doch ich kann jedem empfehlen, diesen zunächst unrealistisch erscheinenden Versuch zu machen, ganz gleich wie groß und schwer die Zielerreichung erscheinen mag. Wichtig ist hierbei nur, die Gesamtverantwortung des Prozesses, des Gelingens und der Ergebnisse nicht alleine als Facilitator stemmen zu wollen, sondern diese auf alle Schultern des Teams zu verteilen. Und genau das ist ganz im Sinne des Design Sprints und der Agilen Produktentwicklung.
