Book Review: "Sprint"

Geschrieben von Jenny Funk veröffentlich am in der Kategorie

Die Autoren Jake Knapp, Braden Kowitz und John Zeratsky arbeiten bei Google Venture (https://www.gv.com), dass in Start ups investiert, die nicht immer Erfolgsgaranten sind. Neben den reinen Investitionen begleitet Google Ventures quasi als Beratungsunternehmen die Produktentwicklung.

Durch Beratungen von über 300 Startups haben Knapp, Kowitz und Zeratsky bei Google Ventures viele Erfahrungen sammeln können. In ihrem Buch „Sprint – Wie man in nur fünf Tagen neue Ideen testet und Probleme löst“ (2016) haben sie einen Prozess beschrieben, der über die Erfahrungen hinweg bei den Start ups zu Erfolgen geführt haben.

 

Prozesse sind Teil der Beratung und Beratung bedeutet Vertrauen

Die Etablierung eines Prozesses oder eines Vorgehens erfordert auch immer Lernbereitschaft. Als Agentur können wir unsere Kunden nur beraten, wenn uns Vertrauen entgegen gebracht wird. Und Beratung, so ist unsere Welt eben, hängt auch mit Zeit und damit mit Geld zusammen. „Lassen Sie sich führen“ ist in Zeiten gefühlter Unsicherheit schwieriger geworden.
Google Ventures ist in der luxuriösen Situation, beraten und Einfluss nehmen zu können, ohne dass ihnen Vertrauen entgegen gebracht werden muss: Als Investoren werden sie immer ein Mitspracherecht einfordern können. Und da auch bei ihnen Zeit Geld kostet, haben sie einen Prozess entwickelt, der Fortschritt in kurzer Zeit verspricht. Die Frage ist: Was können wir von den Erfahrungen von Google Ventures lernen?

 

Vorwort & Einleitung

Vorab soll darauf hingewiesen werden, dass in der Schreibweise durchaus eine gewisse amerikanische Attitüde zum Vorschein kommt, vieles als „exciting“ oder „great“ zu beschreiben. Der Autor gibt bereits in seinem Vorwort erste Hinweise, welche Aspekte im Sprint eine Rolle spielen werden:

  • Kritik an kollektiven Brainstorming-Workshops – beste Ideen kommen „unterwegs“
  • Kleine Deadlines, um den Fokus zu schärfen
  • Effizienz und Effektivität zu erzielen
  • Bereitschaft der Team-Mitglieder, jederzeit Fragen beantworten zu können
  • Durch Räumlichkeiten enge Kollaboration schaffen

 

Knapp erläutert, dass die Ideen aus den Sprints anhand des Nutzerverhaltens in der Praxis getestet werden. Im Falle von Gmail, Google Ads, Chrome, Google Search und anderen Alphabet-Ablegern werden Erfolge von KPIs, die an die Nutzer gekoppelt sind, als Erfolgs-Indikator überprüft aber eben auch „ernst genommen“.

In der Einleitung geht es um das praktische Beispiel, einen Hotel-Service-Roboter, wovon es bereits einen physischen Prototypen gab, für Tests zu gestalten. Folgende Planung wurde aufgestellt:

  1. Das Projekt-Team hat zunächst jegliche andere Termine gestrichen und sich für eine Woche lediglich der Ideenfindung verschrieben. Es gab also keine Ablenkung und keine Ausrede, nicht darüber nachzudenken.
  2. Montag: Erstellung einer Übersicht zu Problemfindung, Risiken, Herausforderungen: Menschen sollen sich vor dem Roboter weder fürchten noch genervt von ihm sein. Es wurde festgelegt, welche Aufgabe der Roboter erfüllen bzw. welche Aufgabe getestet werden sollte. Und welche Roboter unsere Kultur bereits positiv beeinflusst haben u.a. R2D2 😊
  3. Dienstag: Problemlösungen finden und skribbeln – jeder einzelnd.
  4. Mittwoch: Schaffung eines Ideen-Boards und gemeinsame Besprechung dieser Ideen (wir erinnern uns an dieser Stelle an das Design Studio). Die 23 Möglichkeiten wurden per Wahl priorisiert.
  5. Donnerstag: Bau eines Prototypens, der einigermaßen behelfsmäßig konstruiert wurde u.a. mit einem iPad als „Gesicht“.
  6. Freitag: Interviews mit Hotelgästen, die nicht wussten, warum Reise-Interviews im Hotel mit ihnen geführt worden sind. Es wird an dieser Stelle nicht dargelegt, wie und wann das Testszenario aufgestellt wurde und auf welchen Kriterien das Interview basiert sowie welche Ergebnisse erwartet worden sind.

 

Hier ein Video von dem Hotel-Roboter https://youtu.be/SEuaugwnW6A und von der Entwicklungsgeschichte https://youtu.be/AiZj7LTMjzs

Die Autoren geben vorab an, dass es ein „Do it yourself“-Buch ist, dass nicht auf high-level-Basis Ratschläge gibt, sondern detailreiche Informationen preisgibt, auf dessen Basis schnellere und erfolgreichere Fortschritte für das jeweilige Produkt möglich werden kann. Auch wird darauf hingewiesen, dass einiges bereits aus dem Lean-Ansatz oder dem Design Thinking bekannt sein wird, anderes aber neu sein wird.

 

Kapitel „Set the stage“

  • Die richtige Herausforderung
  • Hier wird über den Sprint mit Blue Bottle Coffee erzählt, eine Firma, die damals noch keinerlei Online-Erfahrung hatte. Der Sprint hatte einem Team aus mehreren Personen des Unternehmens dazu verholfen, das Unternehmen in die richtige Spur für den Abverkauf im Online-Geschäft zu bringen.
  • Das richtige Team
  • maximal sieben Personen
  • z.B. mit einem Entscheider, Designer, Entwickler, Logistiker, Kundenservice, Finanzbeauftragter, Marketer
  • für die Herausforderungen am Montag können weitere Experten geladen werden
  • für Zwischendurch: Der „Troublemaker“, der möglicherweise nicht dem Team zustimmt, sondern es herausfordert
  • einen Moderator – und dieser sollte nicht der Entscheider sein!
  • Zeit
  • Ein schöner Ausdruck ist „Fragmentierung stört Produktivität“ – deshalb ist es wichtig, einen Fokus und eine Deadline zu setzen und auch mit den Uhrzeiten dafür zu sorgen, dass die Sprint-Teilnehmer nicht müde sind. Die Idee ist, eine Vormittags-, ein Mittags- und Nachmittagspause zu planen. Handys und Laptops sind während der Konzentrationszeit verboten, weil sie ablenken.
  • Raum
  • Whiteboards. Immer wieder Whiteboards. Zwei Stück. Und Papier. Und ein Sprint-Raum, in dem sich alle treffen und der die Hoheit des Teams sein soll (wir erinnern uns an das Prinzip des War-Rooms). Und für den Moderator gibt es möglicherweise noch eine Stechuhr.

Prototypen müssen nicht perfekt sein, sondern sollen lediglich dazu verhelfen, erste Antworten zu bekommen. Es muss groß gedacht, aber klein gehandelt werden. Zudem, so die Autoren, ist immer auf die Bedienungsoberflächen zu achten, da Menschen hier interagieren.

 

Von Montag bis Freitag

Die Autoren beschreiben anschließend die einzelnen Tage. Um an dieser (Kern-)Stelle nicht allzu viel vorweg zu nehmen, sei gesagt, dass das Buch viele Ratschläge zur Kommunikation enthält: Von den Ausgangsfragen („was brauchen unsere Kunden“) bis hin zu unkomfortablen Situationen, wenn die persönlichen Ideen in einem hohen Tempo (weil timeboxed) kritisiert werden.

 

Google Sprint Ablauf

 

Des Weiteren werden zusätzliche Hinweise für den Moderator zur Verfügung gestellt, die ihn oder sie dabei unterstützen soll, die einzelnen Sprint-Bestandteile in die richtigen Bahnen zu lenken.

Es ist bemerkenswert, das an vielen Stellen von Gefühlen, Konflikten und Erfolgen innerhalb dieser Tage erzählt wird. Vermutlich spiegelt sich die Spannung, die ein Team sich mit den Deadlines und einem klaren Fokus selbst auferlegt, hierin wider.

 

Checklisten

In der englischen Version des Buches gibt es 17 Seiten mit Checklisten, die uns bei der Sprint-Umsetzung helfen sollen. Noch praktischer wäre natürlich ein kleines Buch gewesen, etwas zum heraustrennen oder eine Download-Möglichkeit, sodass man die Checklisten einfach mit ins Meeting nehmen könnte. Hier haben sie selbst scheinbar keine kundenfreundliche Ideen entwickelt 😉

 

Fazit

Das Buch erzählt viele Geschichten. Spannende aber auch weniger spannende. Immer wieder wird Bezug zu Filmen, Büchern oder Ereignissen genommen, was irgendwann als störend empfunden werden kann. Auch die amerikanische Ausdrucksweise ist in diesem Buch, sagen wir gewöhnungsbedürftig. Ein bisschen mehr Sachlichkeit hätte nicht geschadet.

Insgesamt gibt es Neues aber auch Altes zu erfahren. Die große Herausforderung solche Sprints zu realisieren ist ein gewisser Druck, wirklich etwas erreichen zu wollen und die Bereitschaft, einen solchen Sprint durchzuführen. Der Vorteil an diesem Sprint ist, dass er fünf Tage dauert und am Ende ein Ergebnis in Bezug auf Nutzer- und Kunden-Meinungen hat. Anschließend muss entschieden werden, wie viele Iterationen dieser Sprints folgen müssen, um die Arbeit zu einem definierten Abschluss zu bringen.

Für diejenigen Teilnehmer, die einen Prototypen vor dem Testen (innerhalb eines Tages) bauen müssen, muss eine große Mitbestimmung zuteilwerden, was genau realisierbar für sie ist. Nichtsdestotrotz kann dieses Sprint-Prinzip sehr gut funktionieren, wenn ein Prototyp eben einfach gar nicht allzu kompliziert gedacht wird. Zudem kann vom Team auch andere Zeitfenster bestimmt werden, wie Jennifer Pepper von Unbounce hier erläutert .

Wie eingangs beschrieben, werden auch durch solche Sprints Erfahrungen gesammelt und das Prinzip für die anstehende Herausforderung und das jeweilige Team angepasst. Nichtsdestotrotz ist vermutlich eine zunächst enge Anlehnung an die Theorie empfehlenswert um auch das Prinzip des „fail fast“ zuzulassen.

Alles in allem ist das Buch lesenswert, wenn dabei bedacht wird, dass hier kein großer inhaltlicher Wurf zu erwarten ist. Pragmatisch gesehen ist das Buch eine Ergänzung zum klassischen Lean-Ansatz, denn es macht den Prozess lebendiger durch all die Projekt-Erfahrungen, die beschrieben werden. Zudem gibt das Buch einem Team durchaus interessante und hilfreiche Regeln an die Hand.