Google Design Sprints – wie Design Thinking auf Speed, aber nicht im Flow
Frage: „Wie lange braucht ihr noch?“
Antwort: „Nicht mehr lange, aber genau können wir das nicht sagen.“
Wenn Sie und Ihr Team in Projekten unbekanntes Gelände betreten oder ein besonders kniffliges Problem lösen müssen, könnten Sie das schon so gehört haben. Die Antwort ist natürlich unbefriedigend, denn schließlich haben Prozesse im Normalfall eine Deadline. Aber Vorsicht! Denn es kann gut sein, dass sich Ihr Team gerade im Flow befindet. Und diesen Zustand sollten Sie unbedingt fördern.
Bitte nicht stören – wir sind im Flow
Das Team arbeitet konzentriert, hat sich bis ins unbekannte Terrain vorgekämpft. Die Konzentration ist gestiegen, der Druck auch. Im Flow befinden sich seine Mitglieder in einem Zustand gemeinsam erlebter Schaffenskraft und Kreativität. Entsprechend heißt die Antwort übersetzt: „Bitte nicht stören.“
Der Flow-Zustand
Der Begriff „Flow“ geht auf den Psychologen (mit dem fast unaussprechlichen Namen) Mihály Csíkszentmihályi zurück. Das Flow-Konzept beschreibt einen Bewusstseinszustand der Auftritt, wenn eine sich steigernde Herausforderung auf eine gleichzeitig ansteigendes Gefühl von wachsenden Fähigkeiten trifft.
Flow ist ein Gleichgewichtszustand, der sich für Menschen sehr gut anfühlt und die Produktivität immens steigern kann.
Es lohnt sich, das Konzept des Flows genauer zu erforschen (Bei der Recherche wird man auf bekannte Namen wie Kurt Hahn und Maria Montessori stoßen…), denn bei der Lösung von echten Herausforderungen, wird es immer wieder um diesen Zustand gehen.
Flow kann man nicht „machen“
Flow ist ein Glücksfall für ein Projekt-Team, aber leider ist der Flow-Zustand nicht stabil. Steigert sich die Herausforderung, der das Team begegnen muss, und führt zu einer Überforderung, steigt der Stress-Level und der Flow ist zerstört. (Und wir wissen alle, was in diesem Kontext beispielsweise nahende Deadlines bedeuten können.)
Natürlich ist Flow ein Glücksfall für ein Projekt-Team, aber dieser labile Zustand hat einen sehr großen Nachteil: Er ist kaum von Außen zu steuern. Flow kann man nicht machen – Flow entsteht, weil positive Bedingungen vorherrschen. Das gilt für die menschliche Einzelleistung und noch mehr für die Gruppe. Daher müssen wir in unserer Projektpraxis genau hinsehen, welche Bedingungen Flow fördern, oder bremsen. Das gilt natürlich vor allem für die gewählten Arbeitsprozesse.
Flow kann man nicht „machen“ – Flow entsteht, weil positive Bedingungen vorherrschen.
Felix Guder
7 günstige Bedingungen für Flow:
- Man weiss was man tut
- Man weiss wie man es tut
- Man spürt das es läuft
- Man weiss wohin die Reise geht
- Die Herausforderungen sind hoch
- Die eigenen Fähigkeiten ebenso
- Niemand stört und unterbricht den Flow
Schaffer (2013)
Iterative Prozesse fördern den Flow
Grundsätzlich gilt: Ein Team, das seine Aufgaben und sein Arbeitstempo selbst bestimmen kann, wird viel leichter den Zustand des Flows erreichen, als ein Team, das sich in einem sehr starren Korsett aus Zeit und Aufgaben bewegt. SCRUM ist deshalb so erfolgreich, weil es als agile Methode eine extreme Leistungssteigerungen der Teams ermöglicht. Aber leider ist SCRUM eine Umsetzungsmethode, kein Kreativ-Framework.
Auf den ersten Blick sieht auch Design Thinking vielversprechend aus: Teamwork, ein vorbereiteter Prozess, ein hohes Maß an Selbstbestimmung. Eigentlich ideal. In der Praxis zeigt sich allerdings, dass Design Thinking innerhalb der verschiedenen Phasen unterschiedliche Herausforderungen für einzelne Teammitglieder bereithält. Während ein Teil der Gruppe sich beim Ideation-Prozess unterfordert fühlt, erlebt der andere Teil der Gruppe einen Moment der Überforderung. Dieser Effekt verstärkt sich, je heterogener das Team ist, je unklarer die Zeitvorgaben sind und je unbekannter das Ziel ist. Diese drei Faktoren sind aber der Theorie nach Erfolgsfaktoren von Design Thinking.
Die Abwesenheit von Flow ist daher ein bekanntes Phänomen von Design Thinking, was immer wieder zu dessen Ablehnung führt.
Google Design Sprints sind Design Thinking auf Speed
Von einer vermeintlich einfachen Möglichkeit, die Leistungsfähigkeit von Design Thinking zu steigern, hört man derzeit überall. Gemeint ist: Der Sprint! Denn „Sprint“, das klingt ja auch schnell. Kurze Taktung erhöht den Druck; die Anforderungen steigen, das Team performt. Der Design Thinking Sprint ist geboren!
10 Tage, 5 Tage, die Taktung sinkt. Aber was bedeutet das für den Output?
Führen wir uns nochmal vor Augen, was Überforderung bedeutet: Sie erzeugt Stress, manchmal sogar Angst. Zwar sagt der Volksmund, Not mache erfinderisch. Damit ist aber nicht Zeitnot gemeint! Denn letztere führt zu einer panikartigen Verengung des Blickfeldes. Mit anderen Worten: Stress schränkt den Möglichkeitsraum von Design Thinking ein, und zwar gewaltig.
Zwar sagt der Volksmund, Not mache erfinderisch. Damit ist aber nicht Zeitnot gemeint!
Felix Guder
Der Aufbau von Google Design Sprints
Dem Namen nach mögen sie erstmal gut klingen – schließlich ist Google eines der innovativsten Unternehmen der Welt – aber Google Design Sprints sind als Methode sogar noch radikaler. Und bei genauerem Hinsehen zeigt sich eigentlich, dass der Prozess das Wort „Design“ zu unrecht im Namen trägt.
Google Design Sprints organisieren einen Teamprozess zur Lösung eines Problems in 5 Tagen. Vom Problem bis zum Test eines Prototyps vor dem Kunden:
Tag 1 (Montag):
Verstehen
Kunden, Markt, Chancen. Danach ein Ziel definieren.
Tag 2 (Dienstag)
Skizzieren:
Lösungen entwickeln und die Kunden für den Test am Freitag organisieren.
Tag 3 (Mittwoch)
Entscheiden:
Welche Lösung soll am Freitag wie getestet werden?
Tag 4 (Donnerstag)
Prototyping:
Ausarbeitung des Prototypen für das Testszenario.
Tag 5 (Freitag)
Testen:
Vor Kunde, mit einem überzeugenden Prototypen.
Innerhalb dieser Woche bieten Google Design Sprints eine Reihe von Tools, mit denen man diesen Prozess ausgestalten kann. Das klingt erstmal gut: Ein Prototyp innerhalb von einer Woche. Aber mal ehrlich – keine User Research, kein Kontext, keine Empathie? Und nur einen Prototyp, den der Kunde beurteilen, aber nicht vergleichen kann? Ist das Nutzerzentrierung?
Und jetzt stellen wir uns ein richtig heterogenes Team vor: Ein paar kreative Köpfe, die andauernd den Status Quo hinterfragen, ein paar Experten für die Technik, für das Marketing und für die Entwicklung. Da wird es introvertierte Charaktere geben, die alleine bis Mittwoch Zeit brauchen, um genug Vertrauen in das Team zu entwickeln. Bis dahin werden die kaum Input geben – und schon gar nicht am ersten Tag. Und die Kreativen müssen am zweiten Tag liefern ohne das Thema in seiner Breite ausgelotet zu haben. Den Rest der Woche kämpft man sich gemeinsam durch den Bau eines Prototypen. Damit ist die typische Arbeitswoche gefüllt und fairerweise kann man sich dann an Tag 6 und 7 in geradezu himmlischer Ruhe entspannen. Die im Umfeld von Google Ventures entwickelte Methode klingt wie Design Thinking auf Speed.
In nur 5 Tagen eine Lösung?
Der Vorteil: Beim Google Design Sprint muss jede Lösung nach 5 Tagen als Prototyp überzeugt haben… oder sie wird verworfen. „Fail early!“ Damit ist eines der wichtigsten Prinzipien des Lean Management bereits umgesetzt.
Allerdings beschränkt die Methode dadurch auch ihre Wirksamkeit. In 5 Tagen kann man mit einem multidisziplinären Team bestehendes Wissen zu einem überzeugenden Prototypen weiterverarbeiten, aber eine tiefergehende Beschäftigung oder gar Wissensgenerierung kann in dieser kurzen Zeit nicht stattfinden. Ohne Research wird der Möglichkeitsraum des Teams nicht erweitert, von einem Teambuilding-Prozess ganz zu schweigen.
Die ersten Erfahrungen zeigen: Diese Sprints sind extrem labil.
In den ersten Versuchen passiert eigentlich gar nichts. Die getesteten Prototypen lösen, wenn überhaupt, nur Teilprobleme, von der Generierung von tragfähigen und unerwarteten Ideen – keine Spur. Damit bleibt die Methodik bei hohen Erwartungen schon hinter den Möglichkeiten von SCRUM zurück, denn Teambuilding-Maßnahmen wie Retrospektiven oder das gemeinsame Schätzen, die im SCRUM-Prozess vorgehesenen sind, fehlen völlig.
Damit eignet sich der Google Design Sprint nicht, um die Probleme von Design Thinking zu lösen. Die liegen nähmlich nicht in der zu langsamen Entwicklung von Prototypen. Und auf den Flow-Zustand, der für das Lösen komplexer Probleme so wichtig ist, kann man bei dieser Methode lange warten.
Prozesse sollten den Menschen dienen – nicht umgekehrt.
Auch Google Design Sprints folgen als Framework einem Trend, der Prozesse zur Antwort auf die steigenden Herausforderungen in den Unternehmen erklärt. Dabei werden die Ansätze zunehmend radikaler. Es kann sein, dass Google Design Sprints für das ein oder andere Start-up die Erleuchtung sind, es kann auch sein, dass man mit der schnellen Umsetzung dem Prototyping auf die Sprünge helfen kann; aber im Kern bedeutet diese Vorgehensweise: Die Menschen werden dem Prozess unterworfen.
Die Gefahr ist sehr groß, dass hier dem Prozess gedient wird, statt dass der Prozess den Menschen dienen würde. Eine Gefahr, die wir auch im Design Thinking vermehrt beobachten können: Der Prozess wird minutiös und Methode für Methode durchgearbeitet. Innovation am Fließband – ein Algorithmus bestimmt die kreative Freiheit. Die Ergebnisse bleiben dann aber hinter den Erwartungen zurück. Genau auf diese Entwicklungen wollten wir mit unserem Strategic Design Framework eine Antwort geben und die Balance wiederherstellen. Denn sinnvolle Innovationen lassen sich nur mit den Menschen bzw. Mitarbeitern gestalten, und nicht gegen sie.
