Sprints are all the rage, but beware the snake-oil! This is what I learnt by taking part in a modified design sprint, run by people with incomplete understanding of the Google Ventures Design Sprint process.
Jake Knapp describes Design Sprints as a greatest hits of productivity, decision making, innovation, creativity, and design — and I think that’s true. But I recently took part in a sprint which modified this “greatest hits” formula heavily. My gut feeling was that these modifications were not beneficial, but since I was unfortunately not in a position to change the process, I chose to view it as an opportunity to gather data, and do a comparative analysis between this sprint, and the GV process outlined in the book — to learn, and to be more prepared for the next time around.
I’m not going to go into specifics about the GV Design Sprint process.. all that stuff is in the book, which you should definitely read — but here is a boiled-down outline of the process:
A Design Sprint is a learning loop where you define and create something (an “it”) you need to learn about. You test with real users, and gain valuable feedback and insights.
Here’s the stuff I learnt by taking part in a ‘bad’ sprint
Don’t change the vision / foundation during the process
This should be a no-brainer, but do NOT, under any circumstances start revising the foundation of the sprint, which was defined at the beginning of the process. In our case, assumptions, questions, goals and problems were literally revised on the last day of the sprint, rendering much of the process pointless, since everything in the sprint is built on top of this foundation. Mess with the foundation — and the whole house comes crashing down.
Don’t rush the time when sketching ideas
We only had very limited time (a few 10-minute slots) for sketching out ideas, which led to little time for exploration. The ideas that resulted seemed to be “shallow” and uninteresting. This belittles the true power of sketching: it is a formational activity which supports emergence of new ideas, and elaboration of existing ones. Sketching is a language which shapes and adds to the ideas which are put down on paper — but it takes time to explore, and go past the obvious ideas.
Don’t go backwards in the process
In this case, the facilitators asked us to review the solution after we had already picked and elaborated it. This led to a random features being added, a general lack of focus, and a bad group dynamic where some group members dominated the discussion.
Don’t test multiple “its” in the same sprint
We ran a sprint over three days, with each day dedicated to a different “it”. This led to two issues. First, ideas spilled over from one day to the next. Ideas that had been discarded on day one, would be “frankensteined” alive again, on days two and three. People get attached to their ideas, and it showed! Second, there was a lack of clarity about the purpose of the sprint, which led to a lack of focus and slow momentum.
Don’t hand off the actual building of the “it”
In our case we had a 3rd party standing by to translate our sketches into finished layouts. And while this was convenient and easy for us, it is super important for people to get their hands dirty, and build whatever they’re going to test, for themselves! It teaches the importance of being specific and detailed, it shows how new issues emerge during such a process, and it provides first-hand experience of how easy it actually is to create a “just-real-enough-to-test” facade of an artefact.
Do stay neutral if you are facilitating a sprint
Our facilitators took active part in the sprint. This might have seemed like a good idea, but since they were also facilitating, they were in a position of authority, and ended up influencing many decisions which should have been in the hands of the sprint team. Facilitators are people just like the rest of us — they can also get attached to their ideas, suffer from biases. So don’t get actively involved if you are facilitating a sprint — stay neutral.
Be mindful of group dynamics
In our case, dot voting / heatmaps was done after people had explained their ideas and concepts. So there was full disclosure about which sprinter had sketched which ideas — this led to unfortunate group dynamics and biased voting.
State explicitly which mindset you should adopt in a sprint
A lesson which is perhaps the most important one, especially if you are sprinting with people who are new to design thinking and design in general: be extremely mindful to explicitly state what sort of mindset one should adopt in a sprint. Specifically, outline what design is, and what wicked problems are. Provide a warm-up exercise such as the 30-circle challenge. Explain the importance of not falling in love with your ideas — that you should fall in love with the problem instead. You should fall in love with the “it” you are trying to figure out how to solve.
Final thoughts
Some good did come out of the sprint — specifically, three prototypes, ready for testing. It will be interesting to see what kind of user feedback the prototypes can generate. My hypothesis is that it will be fairly broad and hard to decipher, but time will tell.
Despite this somewhat critical article, the sprint was a good experience for the team, and it demonstrated (to some extent, at least) how collaborative ideation and sketching works wonders when designing new concepts.
This article was originally published on Mogen's Medium page.
