The Sprint and its Origins

Preface

One of the reasons for this series and my personal & professional opinion on the Sprint is that, eventually, it's a dishonest process.

Many people own the Sprint book. Most flipped through it and studied the facilitation checklists on p. 232 ff. But, let's be honest, almost no one actually read it. So, through time and word of mouth, many implicit remarks and details that – under specific circumstances make the Sprint a powerful process – got lost.

This isn't even necessarily "the fault" of Jake Knapp or the book itself. It's a pattern we can observe with many concepts (like Agile). They are hyped, introduced to the main market, simplified, repeated, and eventually lose their strengths.

What's left of the Sprint today is a workshop concept of false expectations that doesn't acknowledge the people who adopt and participate in it.

Here are some of my core issues with it:

• The Sprint itself is not a user-centric process; it is built on the experience and intuition of participants since users are only involved on the last day
• The Sprint, therefore, doesn't acknowledge the expertise and experience that participants need to have about the problem beforehand. It sets them up to fail, instead.
• The Sprint amplifies decision-making biases and fallacies such as cherry-picking, confirmation bias, availability bias, groupthink and risk aversion
• Only 10% of Sprint time is actually used ideation / creative thinking
• With its claim to be a universal method, the Sprint is used for the wrong use cases

We'll explore these points throughout this little series. If there are parts where you disagree with me or have different experiences, please tell me. I'd like to know about it. Just send me a message. But for now, please keep in mind that I will have this bias in my analysis.

First things first, let's aim for a shared understanding.

What's the Sprint?

The Google Design Sprint is a very tightly structured sequence of workshop activities over 4 to 5 days to develop and test a prototype. Here is how a simplified timetable for a Sprint workshop looks like.

Day 1: Get together, describe the goal of the week, gather expert input/perspectives, decide on one problem to solve
Day 2: Inspire each other with examples and best practices, develop and sketch ideas
Day 3: Present and discuss ideas, decide on the best one, draw up a storyboard as a requirement for the prototype
Day 4: Organize and structure the day, assign responsibilities, then prototype and refine it
(parallel Day 1-4: prepare the testing, draw up the interview outline)
Day 5: Get real-world feedback on your prototype, summarize findings

Jake Knapp mentions in his writings that the core process of the workshop week is adapted from Design Thinking workshops as established at IDEO and taught at the d.school of Design Thinking. But: The Sprint is not Design Thinking, it just draws from its principles. And that's really important to understand.

Because what Design Thinking tries (and succeeds in) is making creative and design processes more accessible to people who wouldn't describe themselves as inherently creative. They can be scientists, managers, controllers, janitors – just everyone. In the understanding of design as the ability to design/shape your environment, everyone is a designer. Everyone is responsible for and active in designing their environment.

With this goal in mind, researchers and designers (since the 1980s) have aimed to understand how internal creative and design processes work – and transform them into methods and processes. The image below is the Design Thinking model currently used by the d.school at Hasso-Plattner Institute in Potsdam. It's one of many abstractions of a design process.

Please note that it consists of 6 phases and that the Sprint effectively cuts the first two: Understand and Observe. It's those two that a) make Design Thinking a user-centric process because you try to empathize with people and situations you are not familiar with and b) are most important to solve any problem.

A second aspect to please take note of is the interconnectedness of the phases. It is not linear, going from A to B but actively iterates and constantly questions itself.

You probably know the Double Diamond model, but I'm purposely not showing it as a reference point for Design Thinking since it's also a simplification that often lacks the notion of a circular process.

Just two more things to add regarding the Design Thinking process:

1. While many coaches compress it into single-day to full-week workshops (and many serious DT practitioners are very unhappy with that), it was intended (and is taught) as a 6 weeks to 3 months project.
2. While many DT participants lack the knowledge of the industry/field of the problem they are trying to solve, the teams are actively recruited with a diversity of thought, skills, and socio-demographics in mind -- to introduce different insights and perspectives.

So in relation to DT, think of the Sprint in this way: It's a delicious dish that one influencer composed from a buffet, becomes insta-famous, and from there on, everyone visiting the restaurant picks the same dish even though there's so much more to offer.

Sidenote: Attitudes towards applicability

The same can be said about the application of other methods. One philosophy that stood out to me is Ohnō Taiichi's "Toyota Production System". While Taiichi explains core methods like kanban and kaizen management, the emphasis is less on the actual steps, and more on the premises and values that lay its foundation.

If the kaban system is introduced without being part of a total philosophy, however, I feel problems will ensue. The system did not happen over night but through a series of innovations – a method developed over 30 years to improve overall efficiency and to improve the work environment. Rintarō Muramatsu, professor for Science and Engineering, in the foreword of "Toyota Production System"

Jake Knapp also argues that the Sprint concept was created by iterating through 100s of sessions with internal and external teams. But his conclusion is quite the opposite of Taiichi: After this many iterations, it's proofed and ready to be applied by everyone.

Just an observation about the difference between Japanese vs. American culture.

The completely made-up and unauthorized origin story of the Sprint

As I mentioned earlier, the Sprint cuts two essential steps of the DT process: understanding and observing. But in the context of the origin of the Sprint, it makes sense: because people were experts. Because it was developed at Google, back in 2010 (and probably still) one of the most prestigious companies to work for.

From knowing how corporates tick, some remarks in the book and my own experience, here's how I think the first Sprint came to be.

(It's 2010. Somewhere at Google, designer JK and his team hit a roadblock while developing a new feature for one of Google's core products. They meet to discuss their next steps.)

Person 1: I'm out of ideas. We have tried so many approaches to this problem. But none worked.
JK: We can't just stop. The problem is still there.
Person 1: I know, I'm not helpful now…
Person 2: Well, I've got an idea. But it's a really long shot. Do you know Jay Doe? They're a leading industry expert of the skill we'd need to push forward. I know them from my time at another GAFA where I worked before. They are now in a team on a different branch of the Google organization, and we don't have any access to them. But I could ask if they were interested in helping us out?
Person 1: But there's no way their team lead would allow them to join our project.
JK: Well, it's worth a shot. Person 2, could you talk to Jay first?

(Person 2 meets super-in-demand expert Jay Doe for lunch)

Person 2: So, this is where we are. Do you think you could help us out?
Jay: Wow, well, that's a tough challenge. But interesting. I totally understand why you're struggling. But lucky for you, I worked on a similar challenge before. I would love to help you. But I'm so busy. I don't think my team lead would let me leave for another project right now.
Person 2: Well, I think we should try it. Better they say no than we've never even asked. Also, we should leave the headache to JK. *laughing

(JK meets up with the team lead of Jay Doe)

JK: We're stuck on this one. Person 2 talked to Jay, and they immediately agreed that they could help us solve the problem. Is there really no way we could borrow them to help us out?
Team lead: No way. I know how these projects go: First, they'll be on your project "just for a few days", and then the project grows, management becomes excited, and I effectively lose one of my best people.
JK: desperately And what if I could promise you that they chime in, just for a week, five days, and then we'll never ask you ever again for their support?
Team lead: I don't think so…
JK: What if I made a very detailed plan for five days. Maybe, well, what if we had a prototype at the end of the week that marks the end of Jay's involvement?

(Begging and convincing ensues. The team lead eventually agrees to a 5-day body lease, but only under the condition of a very structured and limited process.)

This is, how I imagine, the Sprint was born. In this fake dialogue are some aspects hidden under which the Google Design Sprint works well.

• Google is a very broad company with experts in almost all fields of expertise
• In the war of talent, Google won access to some of the leading experts in central design and tech disciplines, from machine learning to physical product design
• Google is a huge and highly structured company that makes it hard to plan co-creation with these experts
• Google itself is a user-centered, design-focussed company that permanently reviews user feedbacks and iterates their product features
• Products are primarily developed on a feature base and within an existing ecosystem and with existing users
• A dedicated team will take the Sprint results and integrate them into their project

In conclusion: The Sprint is a framework to bridge silos and bring internal experts, who already share a design mindset and have a deep understanding of a problem, from different departments together. Especially in a structured and limited process. It's an efficiency-optimized setup to answer a concrete question that every single one of the participants is qualified to answer.

Applications of a successful Sprint

These observations also reflect situations where I found the Sprint to work well:

• Briefing: When you start a new project and want to make sure you gather insights and ideas from colleagues and experts who are affected by it.
• Rebriefing: When you want to challenge your solution with perspectives from other crafts and departments.
• Breakout: When you need to cut off a short amount of time from your project to explore alternative solutions to the one you already developed.
• Timeout: When you need a different work setup from your daily job to concentrate on a problem with colleagues.

But it also shows the limits to the Design Sprint:

• Design Culture: It won't introduce people to user-centric and Design Thinking methods. It's made for people who already share these mindsets.
• Problem Definition: It won't help you to question assumptions and truly understand a problem that is new to you.
• Replacing a Project: It won't work as a standalone process with no preceding research/strategy phase and no owner who afterward will take the results and work with them.
• Business Transformation: It won't help you develop serious, transformative ideas or business models with an existing team.

In real life, I rarely meet Sprints that fit these criteria. Instead, it is used as a shortcut to the development of a Design Mindset. Bringing people together who are not used to brainstorming and creative sessions, who may not even be experts on the problem they try to solve.

Often the problem or topic is not even defined beforehand. The Sprint then marks the first day of everyone thinking about it. Everything that follows is a reaction to the activities, leading to impulsive and intuitive ideas that have no fundament. This would be fine but conflicts with the workshop's objective of developing innovative and user-centric ideas.

But I also understand why decision-makers turn to it, especially since the book release: It's reliable in uncertain times. You know exactly what you'll get. Therefore, it's easy to calculate and sell internally and, being developed by Google, implies that if you just act like them, you can become like them. A modern, digital, user-centric company.

Next Up: The Diversity of Participants

In the next issue, I will focus on these misaligned situations, especially the people in it: The participants of Sprints, their diversity and the safe space that a Sprint often needs to be.

I hope you found this first overview insightful. Please let me know about your experiences and critiques.