Vorwort

Meine Arbeitsweise funktionierte einfach nicht.

Im Jahr 2003 bekamen meine Frau und ich unser erstes Kind. Als ich anschließend in die Arbeit zurückkehrte, wollte ich, dass meine Arbeitszeit genauso sinnvoll wäre wie die Zeit, die ich mit meiner Familie verbrachte. Ich nahm meine Arbeitsgewohnheiten unter die Lupe und stellte fest, dass ich mich nicht auf die wichtigsten Aufgaben konzentrierte.

Also begann ich, meine Arbeitsweise zu optimieren. Ich las Bücher über Produktivitätssteigerung, erstellte Excel-Tabellen, um zu verfolgen, ob ich effizienter arbeitete, wenn ich morgens Sport trieb statt mittags, oder wenn ich Kaffee statt Tee trank. In einem Monat experimentierte ich mit fünf verschiedenen To-do-Listen. Ja, diese ganzen Analysen waren merkwürdig, aber ganz allmählich wurde ich fokussierter und organisierter.

Und dann, im Jahr 2007, fand ich einen Job bei Google, wo ich die perfekte Kultur für einen Prozessfreak wie mich vorfand. Google ermuntert seine Mitarbeiter zum Experimentieren, nicht nur im Zusammenhang mit Produkten, sondern auch im Hinblick auf die Methoden, die einzelne Mitarbeiter und Teams verwenden.

Teamprozesse zu optimieren, wurde für mich zur Besessenheit (ja, auch das ist merkwürdig). Meine ersten Versuche bestanden in Brainstorming-Workshops mit technischen Teams. Gruppen-Brainstormings, bei denen jeder seine Ideen einfach in die Runde ruft, machen großen Spaß. Nach einigen Stunden hatten wir einen Haufen Klebezettel und alle waren in Hochstimmung.

Doch eines Tages, inmitten eines Brainstormings, unterbrach ein Ingenieur den Prozess mit der Frage: »Woher wissen Sie eigentlich, dass Brainstorming funktioniert?« Ich wusste nicht, was ich darauf antworten sollte. Die Wahrheit war ziemlich peinlich: Zwar hatte ich die Teilnehmer befragt, ob ihnen der Workshop gefiel, aber ich hatte versäumt, die Ergebnisse zu messen. Also prüfte ich die Ergebnisse meiner Workshops, und dabei fiel mir ein Problem auf. Die Ideen, die schließlich umgesetzt wurden und Erfolg hatten, kamen nicht von den Zwischenrufen beim Brainstorming. Die besten Ideen stammten aus einer anderen Quelle. Aber woher kamen sie?

Jeder Workshop-Teilnehmer kam auf seine Ideen genauso, wie er es immer getan hatte – während er oder sie am Schreibtisch saß, in einem Coffeeshop auf seine Bestellung wartete oder unter der Dusche stand. Diese von Einzelnen entwickelten Ideen waren den Gruppen­ideen fast immer überlegen. Nachdem sich die enthusiastische Stimmung der Workshops gelegt hatte, konnten die Brainstorming-Ideen nicht mit den individuell erarbeiteten Lösungsvorschlägen mithalten.

Vielleicht war in diesen Sitzungen nicht genug Zeit, um wirklich tief und umfassend über das Problem nachzudenken. Vielleicht lag es daran, dass die Brainstormings mit Lösungsansätzen endeten, die nichts weiter als Papierskizzen waren, anstatt mit irgendetwas Realistischem. Je länger ich darüber nachdachte, desto mehr Schwächen fand ich in meinem Ansatz.

Ich verglich die Brainstorming-Sitzungen mit meiner eigenen täglichen Arbeit bei Google. Die besten Ergebnisse erzielte ich, wenn ich eine große Herausforderung bewältigen musste und unter Zeitdruck stand.

Eines dieser Projekte fand 2009 statt. Ein Gmail-Ingenieur namens Peter Balsiger hatte eine Idee, wie man E-Mails automatisch organisieren könnte. Ich war davon begeistert – die Methode ist heute unter der Bezeichnung „Priority Inbox“ bekannt – und holte uns eine weitere Ingenieurin, Annie Chen, zur Verstärkung ins Team. Annie war einverstanden, aber sie gab dem Projekt nur einen Monat. Wenn wir in dieser Zeit nicht beweisen konnten, dass die Idee machbar wäre, würde sie zu einem anderen Projekt wechseln. Ich war mir sicher, dass uns ein Monat nicht ausreichen würde, aber Annie ist eine herausragende Ingenieurin, also beschloss ich, mich ihrer Bedingung zu fügen.

Wir teilten den Monat in vier Wochenabschnitte auf. Jede Woche entwickelten wir eine neue Version. Annie und Peter erstellten einen Prototyp und am Ende der Woche testeten wir die Version an einigen hundert Nutzern. Am Ende des Monats hatten wir eine Lösung gefunden, die verständlich war und die die Nutzer sicher gerne anwenden würden. Annie blieb und leitete das Priority-Inbox-Team. Und irgendwie gelang es uns, die Entwicklung in einem Bruchteil der sonst üblichen Zeit zu erledigen.

Einige Monate später besuchte ich Serge Lachapelle und Mikael Drugge, zwei »Googler«, die in Stockholm arbeiteten. Wir drei wollten eine Idee für eine browserbasierte Videokonferenz-Software testen. Ich war nur für wenige Tage nach Stockholm gekommen, daher arbeiteten wir so schnell, wie wir konnten. Am Ende meiner Stippvisite hatten wir einen funktionierenden Prototyp. Wir mailten ihn unseren Kollegen und begannen, ihn für unsere Konferenzen zu benutzen. Nach wenigen Monaten wurde er im gesamten Unternehmen verwendet. (Später wurde eine verbesserte und feinjustierte Version dieser webbasierten App unter dem Namen »Google Hangouts« auf den Markt gebracht.)

In beiden Fällen wurde mir klar, dass ich im Rahmen dieser Projekte weitaus effektiver gearbeitet hatte als in meiner täglichen Arbeitsroutine oder irgendeinem Brainstorming-Workshop. Worin lag der Unterschied?

Erstens hatte man Zeit, Ideen frei zu entwickeln, anders als bei den Zwischenrufen im Gruppen-Brainstorming. Andererseits hatte man aber auch nicht zu viel Zeit. Näherrückende Deadlines zwangen mich dazu, mich zu fokussieren. Ich konnte es mir nicht leisten, mich mit Details aufzuhalten oder mich von weniger wichtigen Dingen ablenken zu lassen, wie oft in meinem Arbeitsalltag. Ein weiteres Schlüsselelement waren die Leute. Ingenieure, Produktmanager und Designer, alle arbeiteten im selben Raum. Jeder löste seinen oder ihren Teil des Problems, und jeder war stets bereit und in der Lage, die Fragen der anderen zu beantworten.

Das ließ mich erneut über die Team-Workshops nachdenken. Was wäre, wenn ich die Workshops um diese anderen magischen Elemente ergänzen würde, die Zeit zur individuellen Problemlösung, die Zeit zur Entwicklung eines Prototyps und eine unverrückbare Deadline? Ich beschloss, diesen Prozess als Entwicklungs-»Sprint« zu bezeichnen.

Wieder einmal nahmen die Google-Teams das Experiment bereitwillig an. Ich führte Sprints für Chrome, Google Search, Gmail und andere Projekte durch – und war begeistert. Die Sprints funktionierten. Ideen wurden getestet, umgesetzt, eingeführt, und das Beste von allem war, dass sie in der echten Welt oft Erfolg hatten. Der Sprint-Prozess breitete sich wie ein Lauffeuer von Team zu Team und von Büro zu Büro aus. Eine Designerin von Google X interessierte sich für die Methode und führte einen Sprint für ein Team in Google Ads durch. Die Googler vom Ads-Sprint erzählten ihren Kollegen davon, und so weiter. Bald erfuhr ich von Sprints von Leuten, mit denen ich noch nie gesprochen hatte.

Ich machte natürlich auch Fehler. An meinem ersten Sprint nahmen vierzig Leute teil – das waren natürlich viel zu viele Teilnehmer, und es hätte den Sprint beinahe gesprengt, noch bevor er überhaupt begonnen hatte. Ich passte die Zeit für die Entwicklung von Ideen und Prototypen an. Ich fand heraus, was zu schnell, was zu langsam und schließlich, was genau die richtige Zeit war.

Einige Jahre später traf ich mich mit Bill Maris, um mit ihm über Sprints zu sprechen. Bill ist CEO von Google Ventures (GV), einer Risikokapitalgesellschaft, die Google gegründet hat, um in vielversprechende Start-ups zu investieren. Bill ist einer der einflussreichsten Menschen im Silicon Valley. Von seinem äußeren Erscheinungsbild her würde man das nicht vermuten. An jenem Nachmittag trug er sein typisches Outfit: eine Baseballkappe und ein T-Shirt, auf dem irgendetwas über Vermont stand.

Bill interessierte sich für die Idee, Sprints in den Start-ups des GV-Portfolios durchzuführen. Start-ups bekommen normalerweise nur eine einzige Chance, ein erfolgreiches Produkt zu entwickeln, bevor ihnen der Geldhahn zugedreht wird. Sprints boten diesen Unternehmen eine Methode, mit der sie in kurzer Zeit herausfanden, ob sie sich auf dem richtigen Weg befanden, bevor sie das Risiko eingingen, ihre Produktideen umzusetzen und zu vermarkten. Mit der Durchführung von Sprints ließ sich viel Geld sparen und gleichzeitig viel Geld verdienen.

Zu diesem Zweck musste ich den Sprint-Prozess jedoch überarbeiten. Ich hatte mich jahrelang auf individuelle und Teamproduktivität konzentriert, wusste aber so gut wie nichts über Start-ups und ihre spezifischen Geschäftsprobleme. Dennoch überzeugte mich Bills Enthusiasmus davon, dass Google Ventures der richtige Ort für Sprints war – und der richtige Ort für mich. »Unsere Mission lautet, die besten Unternehmer auf dem Planeten zu finden und ihnen dabei zu helfen, die Welt zu verbessern«, sagte er. Der Faszination dieser Botschaft konnte ich mich nicht entziehen.

Bei Google Ventures schloss ich mich mit drei weiteren Entwicklungspartnern zusammen: Braden Kowitz, John Zeratsky und Michael Margolis. Gemeinsam begannen wir, mit den Start-ups Sprints durchzuführen, mit dem Prozess zu experimentieren und die Ergebnisse zu untersuchen, um den Prozess zu optimieren.

Die Ideen in diesem Buch stammen vom gesamten Team. Braden Kowitz ergänzte den Sprint-Prozess um Story-Centered Design, einen unkonventionellen Ansatz, der sich auf die gesamte Kundenerfahrung bezieht anstatt auf einzelne Komponenten oder Technologien. John Zeratsky half uns dabei, vom Ende her anzufangen – das heißt, dem langfristigen Ziel –, sodass jeder Sprint die Antworten auf die die...