Design Sprint vs. Design Thinking vs. Agile Scrum
This past week, at Design Sprint Academy, we taught our Design Sprint Bootcamp focused on Design Sprints, Problem Framing, and Advanced Facilitation. As usual, we had a diverse group ranging from innovation professionals to UX designers and product people, from executives tasked with transforming work culture to university professors teaching real-world, problem-solving methods to the next generation.
Not long into the first day, questions started popping:
“How is this different from Design Thinking?”
“Why use Design Sprints and not Design Thinking?”
“When to use Design Sprints and when Design Thinking?”
… and my favorite, which is better?
Of course, when discussing much-hyped topics such as innovation frameworks and digital transformation, Agile also comes into the conversation, often in this context:
“But, we already do sprints”.
So, at the midway point of the week, with questions still flowing, we took a break from our workshop and compared the three approaches, considering these dimensions: definitions, structure, scope, and timeline. We hope this exercise provides helpful answers and clarity. While not intended to be an academic or highly theoretical analysis, these insights are based on our experience with Agile building products for 15 years and then running Design Sprints (and later Design Thinking projects) for the past four years.
Inception
First, it is worth mentioning how these concepts originated.
Design Thinking has its roots in the ’50s and ’60s. As new creativity techniques and design methods were developed, Design Thinking became a new approach to solve problems. It became popular in the ’80s and ’90s as it was taught at Stanford University and then IDEO introduced it to the business world.
The birth certificate for Agile is the now-famous Agile Manifesto from 2001, in which 17 authors proclaimed the core principles and values behind it. Initially meant for software development, today it has become an effective approach to project management/innovation that delivers results and meets expectations with minimal waste of resources.
The Design Sprint methodology was developed at Google in 2010 and made popular when the Sprint book was launched in 2016 by a group of designers working at Google Ventures.
Definitions
Before we dive deep into the comparison, it is important to establish the definitions of each of these terms.
Design Thinking is both a problem definition and problem-solving method. We can use it to discover opportunities, to frame and reframe problems using empathy with our users and customers, and then find solutions through ideating, prototyping and testing.
Agile follows naturally, giving us the means to implement these solutions efficiently. Quite simply, it is a project management mindset.
Design Sprints are purely a problem-solving method. For Design Sprints to work, we must start with a well-defined challenge. Typically, the biggest misuse of Design Sprints is when teams try to use them to define or decide what problem to solve.
Structure or Methodology
We will not go into great detail about what is involved in each of these approaches — there’s a ton of information out there — but I would like to emphasize what we consider to be the key characteristics.
Agile comes in different methodologies, the most common of which are: Scrum, Lean, Kanban, XP, and so on. Regardless of the approach, it’s all about building or executing something interactively and iteratively.
Design Thinking has numerous tools and methods that we can use in any of its five phases: Empathise, Define, Ideate, Prototype, and Test. That makes it a compelling and versatile framework that can be applied to all aspects of business innovation. However, getting started can be intimidating if you are unfamiliar with the process.
The Design Sprint is almost the complete opposite. Instead of a plethora of tools, the Design Sprint has specific exercises for each phase, making it easy to learn and understand.
The simplicity, seemingly quick learning curve, and promise of delivering results similar to Design Thinking have led to its widespread adoption in recent years. No wonder, taking into consideration the similarities between them.
Collaboration
Design Thinking and Design Sprints are highly collaborative and involve cross-functional teams working closely together. This style of collaboration unleashes creativity, makes out-there ideas flourish, and teams can quickly prototype and test the concepts with end-users or customers.
This is what we call rapid prototyping, which allows us to get practically instant feedback and understand why things work (or not), and validate (or not) our concepts. Regardless of the outcome, we learn enough to know how to move forward into the execution phase.
Agile Scrum is similarly collaborative, involving cross-functional teams working together to build something. At the end of the process, there is a finished product, feature or offering we can put in front of the user with the hopes it will work out. Unfortunately, oftentimes it does not work, and we learn this only after investing precious time and resources.
We can avoid this waste and de-risk our projects by running a Design Sprint or Design Thinking process before we commit to executing following the Agile Scrum approach.
Purpose
In our view, this is where it is essential to differentiate between approaches.
Design Thinking encompasses deep context analysis, opportunity mapping, and problem framing. It also contains an extensive library of methods and tools, making it an ideal framework to tackle complex challenges, large in scope, involving multiple stakeholders and customer audiences.
On the other hand, a Design Sprint is best suited for problems with a limited, targeted scope and clearly defined boundaries.
To put it in perspective, if we wanted to introduce and scale an innovation framework into an organization, the choice would be a Design Thinking project because we first need to look at the entire context, including understanding how the organization works today; who are the stakeholders; how new products are developed from inception to delivery; who are the customers, their needs and wants; and how we include them in our workflow. As we do this, we can map opportunities, identify areas of improvement and define the problems and challenges, after which we can tackle them one by one to ideate solutions, prototype them and then test.
In contrast, a Design Sprint would be able to tackle just a fraction of the entire innovation process, say, improving the way we collect and use customer insights.
We can use Design Thinking and Design Sprints to solve problems and get the necessary solutions and answers. Looking at the example above, Design Thinking could answer questions like “How might we become an innovative organization?” The Design Sprint could better address “How might we make better use of customer insights in our innovation process?”
Thus, we can answer broader questions with Design Thinking. The other difference here is that Design Thinking can help determine which question to ask in the first place, unlike Design Sprints, which really aren’t equipped to do so. This leads to one of the biggest pitfalls of Design Sprints — that is, answering the questions no one is asking or needs answers to.
Finally, once we have our answers, we can use Agile Scrum to execute and put them into practice.
Timeline
The last dimension, but surely not the least important, is time. Logically, because Design Thinking tackles more broadly scoped projects, they will take (a lot) more time than Design Sprints.
However, it is not only scope that determines duration.
Design Sprints are a linear process. Once underway, we follow a predetermined set of activities and exercises in a matter of days, typically three to five.
Design Thinking, on the other hand, is a looping process. For example, we can return to problem definition and explore other directions once we refine our ideas and learn more through prototyping and testing.
Design Sprints are best when there is a sense of urgency or when the problem we want to solve is well-articulated, and we need to move fast. To use another analogy, Design Thinking is a marathon, while a Design Sprint is, well, a sprint.
What about Agile? After all, it was Agile that coined the term “sprints.” Simply put, at the end of each Scrum sprint, it may be a week or two — or even up to six weeks — before we get a working increment of our product or service.
At Design Sprint Academy we use the Design Sprint 3.0 and take the best of both worlds: the speed and focus of Design Sprints and the ability of Design Thinking to tackle large and complex challenges. We do that through Problem Framing and a few improvements to the Design Sprint process which you can read about in this article.
