Why I Love Design Sprint Master Trainings — and Why It Takes Two Days to Train the Framework
I have had my own company for 20 years now and have been in Germany for 30 years. In my life, I have worked with an incredible number of great people on projects — eagerly awaiting product completions and having to find unconventional solutions for unrealistic project plans. And I have attended many trainings and held some more myself. Whether as a learner or a teacher — I have always gained new insights. But never before has one of my trainings been as emotional as our design sprint trainings. So today I would like to write a few lines about why I love Design Sprint Master trainings:
In our courses there are participants who have already read the literature, watched videos or podcasts and visited websites and blogs on this topic. Others come from design thinking or follow agile software development methods in their daily work as product owners, software developers or UX designers. They all have something in common: they are interested in the framework but have so far only theoretically understood it and have no idea where to start in order to get the experience in practice. There is a lack of a protected environment, because without experience as a moderator you are alone and mainly responsible for the favorable outcome of the sprint — at least in the eyes of the budget providers.
We conduct design sprint trainings in 3 languages worldwide. Whether we present them in English, Spanish or German, people are always very pleased and grateful not only to be introduced and told about all five phases, but also to experience the sprint process all by themselves: The dynamics in the group, the time-boxing, the voting, the decisions of the decider that are felt to be good and comprehensible or incomprehensible. And above all: The prototype! Without previous knowledge. Without designer skills. Without design-savvy colleagues. And the excitement of having to present the partially functional result to a user and accept the feedback. Design sprints are a framework where nobody can hide and everyone has to get involved if you want to create a collectively presentable result. Therefore the training loses its abstractness after a short time, one leaves the typical “I sit at the table and listen” situation and dives into the team and the given question.
Already in phase 1 (understand) the participants deal with a user, process information on a certain topic, which they have to work on from the beginning to the end of the sprint framework and which they cannot let go. They conduct expert interviews and learn how important it is to create how-might-we-questions and consolidate and review all the different information. You get involved in the process and immerse yourself in the topic. The most exciting to see: While I keep seeing participants stealthily looking at their watches or cell phones in other training sessions, this has never happened to me in a sprint course before. Not even once.
In the second phase (collect ideas & sketch), the Lightning Demos open up worlds and an enormous variety of solutions to a single problem. Until then, the participants were still sceptical about the added value that the whole sprint could bring, and when the problem could be eliminated quite clearly and thus in its solution also simply and straightforwardly. Then amazement and one’s own imagination starts to blossom. The term “steal with pride” and the associated call to unrestrained theft of ideas inspires some participants’ own creativity to such an extent that they transform themselves from reserved team members into the greatest creative theft evangelists. The Crazy 8s really inspire them to the craziest designs, and the biggest groan about the challenges to their own resilience. As a trainer it is incredibly nice to know that at this point all the energy that accumulates and could potentially also turn into frustration and overload can be used and redirected to the liberation and satisfaction that arise at the end of the first training day with the completion of one’s own solution sketch. In addition to this liberation as a trainer, I always feel a little awe as to which innovative solutions the participants develop. It is a very nice, satisfying experience also for the trainer.
When we enter the third phase on the second day and the participants can see the Art Gallery with all its works for the first time, most people are surprised and understand for the first time, apart from any theoretical endorsement of the sprint framework they have read, that the “work alone but as a group” has set the right course for the design sprint. They really stroll around between the sketches like in an exhibition and spend a lot of time in front of some sketches and little time in front of others. Due to my experience as a trainer, I can now read out from the mixture of body language and length of stay which solution sketches will be amongst the favorites and which ones will get fewer dots when we do the heatmap. Later on, each sketch is presented again as part of the speed critique — but this step usually doesn’t change the individual affinity for one or the other solution. However, it helps to show the team once again what they were able to contribute and achieve in such a short time to a completely unknown topic. A trial vote and the decision for a solution, already directed towards prototyping, then reveal affinities and aversions that had been hidden up to then and we shortly discuss ideas that have not been understood until then. We always keep the supportive and friendly atmosphere. Commitment and the exorbitantly grown identification of the training participants with their project in the last two days become more and more obvious. A great experience — and a lecture in why a team is always more than the sum of its members. The storyboard usually absorbs a part of disappointment, when previously deselected elements cheat themselves into the solution again in a very small and hidden way, because their practicability is unbeatable or a decision maker willingly lets his/her decision soften. The nice thing about a training compared to a real design sprint is that you can also let the facilitator role slip, because especially with the examples, if you let the framework get out of control, you can best explain some process steps later with the correction, why you should follow the framework and what makes it so successful.
The prototype shows how well teamed-up the training participants are after one and a half days of training. Everyone has his/her task and a common goal; the prototype must be made available for testing in a short time. The effort in the team is enormous. Everyone’s working feverishly on it. There are fundamental doubts whether this can be achieved and in every training session I experience a happy end: The team always manages it. Like in a really good movie: effort, tension, whether everything was worth it and a liberating ending. I love this atmosphere every time. Sometimes it has the potential for goose bumps.
The tension continues until the user’s interview in the final phase of the design sprint. The team follows the presentation of “their baby” every second. The participants are so involved that they talk about further developments of the product and think about improvements. They are so immersed in the project that they have forgotten that it is “just” a training to teach them the framework. As a coach, I always have a smile on my face after these two days. It is great to see how the participants take the whole thing seriously and fall in love with the topic and their own newly created product.
That’s why I’m going to continue teaching this training in two days and not in a short, compressed one-day course. I want the participants to experience all of the above. I want to have them exhausted and with a smile at the end of the course — because they are satisfied with their own performance and that of the team.