[Brainshot] Is Design Sprint A Necessity?

by Kevin Richard

•

February 03, 2020

•

3 min read

Is one single tool more important than the goals it should help to achieve? Switching the center of discussion.

Recently, Robert Skrobe wrote on LinkedIn an interesting post that, to me, is a sign (if needed) of the maturation of the Design Sprint movement.

Robert Skrobe on LinkedIn: #designsprint | 87 comments
I'm starting to move away from the design sprint methodology that I've been working with for the past three years. Now…www.linkedin.com

Here is an excerpt:

“I’m starting to move away from the design sprint methodology […][What] I am doing is moving more towards my central thesis of 2020 for the process: It will be more about the recipe than the blueprint.
Since Jake Knapp’s original process first debuted in 2016, it’s been modified many times over.
Steph Cruchon created the Design Sprint Quarter. Jeroen Frumau and Sabrina Goerlich have been working on the Talent Sprint with some initial success. Maaike Coppens is ready to set the world on fire with her Voice Sprint process.”

So, why talking about maturation? Well, as you may know, I am a critic of the design sprint as it is sold. Not because “I don’t like it” or “I don’t believe in it” (as a ‘Sprint Master’ once told me), but because it is objectively blind towards the context you are working in and the context for which you are trying to deliver value.

Besides, it is interesting to call for “belief” or “faith” in a discussion about Design Sprint, during which the “best” argument thrown being “it’s not science” along with “you have to trust the process” and “what matters is to validate at the end”. Magical thinking anyone?

Anyways…

My point is: the Design Sprint is a tool, and we need to understand the limitations of our tools to know when and where it is best suited for. As I wrote in my article “How to design in large organizations”:

“A recipe is a formalized process –in other words, a method. It’s a tool to reach a desired predetermined result. [And] a tool is a means toward a goal.[Because] of its very formulation, a tool implies some prerequisites to reach the intended result. Here, it implies that you have access to such ingredients and that you are able to perform such instructions.
In complex organizations, the prerequisites necessary for ready-to-use recipes, methods, or processes are not guaranteed. Sometimes you don’t have all the ingredients. Sometimes, you can’t perform all the instructions. And quite often, it’s a bit of the two. In fact, in such environments, it is impossible to control all the variables that lead to a desired state. Our tools, methods, and processes are, by design, ignorant of this reality.”

Therefore, it is not surprising that people tend to modify their tools to better fit their context(s). The various adaptations of the Design Sprint are an expected observation (evidence?) of this reality.

Question: How far should it go? I mean, will it make any sense to call it “Design Sprint” at some point? Will we realize that Design Sprint or not, what matters is that it helps to reach our goals/intents?

With my team, we created “sessions” designed for the very specific challenges we were facing. This requires understanding your environment, recognizing what people value, what it means to them.

For this, I don’t call these sessions “design sprints” because:

We don’t care if people recognize it as a specific approach;
We didn’t wait on the design sprint to recognize that any type of directed & time-boxed sessions lead to results;
We don’t want people to believe a specific method is all that they need because it would be at best a misinformed recommendation — and at worst a lie;

What we care about, however, is what people got from it and what they do with it now.

In the end, what does matter the most? That we use “Tool X™️” for all types of problems OR that we used the best methods to reach our goals/intents in the best understanding of the problem space?

*best being variable depending on the context.