Key Learnings from Designing a Remote Multi Sprint Event

This is a reflection on learnings on designing the Digital Health and Wellbeing Sprint Event, a Remote Design Sprint. I should say sprints, since we actually run simultaneously 8 sprints with teams that were working with 6 different startup companies in the health and wellbeing sector.

The sprint teams were students of three universities of applied sciences in the Helsinki region (Laurea, Metropolia and Haaga-Helia). We were a team of 5 facilitators, a project manager and three teachers from the universities, and 40 students in 8 sprint teams. As we are in times of corona, the sprint which was originally supposed to be a face-to-face event was moved online.

We used the Google Sprint methodology created by Jake Knapp – though we made some adjustments to timing, extending the sprint to seven days from the original five, added some inspirational speakers and a final pitching event for the sprint teams to present their solutions to the companies. The new Remote Design Sprint Guide was a very useful resource for us when designing. The online tools we used were Zoom for sound and video connection and Mural as virtual whiteboard tool. We also used a Mural template for remote design sprints (which doesn’t seem exist on Mural anymore).

Every day we congregated in Zoom, where the teams would get instructions about methods for the day and then work in their challenge in breakout rooms, on their team Mural boards. The teams had no facilitators, but worked in a self-organizing manner, and had help from the facilitator team whose members would pop in periodically to ask if everything was going smoothly. Some days the teams had more independent time and no support from facilitators.

Main learnings from Digital Health and Wellbeing Sprint

Formulate the Right Challenge

Sprint as a methodology is different from some other human centric design methods, since it doesn’t allow much time for exploring and scoping down a problem. Also, the sprint is not an ideation method producing loads of out-of-the-box ideas, instead the beauty and efficacy of the sprint lies in the fact that within five days of working together you will have a functioning prototype of your solution, tested on real users.

This means that the challenge or problem for the sprint needs to be formulated properly. A too broad challenge won’t bring sensible results and will be frustrating for the team working on it. Some of the challenges we worked with were somewhat too broad, though I’m very grateful to my facilitator colleague Cecylia Kundera who did a lot of work in trying to make the best out of the challenges. The challenge needs to be formulated in a way that allows the group to start thinking about solutions right away – for example having a set target group or not having several different questions in the challenge.

A Sense of Community Doesn’t Just Happen Online

A sense of community doesn’t just appear in an online event in the same way as in a face to face event. There are ways of how a sense of community can be enhanced during the event. We had a Mural board that people would fill in with a few details and pictures about themselves before the design sprint. During the sprint we had a morning and evening one word check-in in the chat, which was a great way to gauge the feelings of the sprint teams. As expected, there was much excitement in the beginning and somewhat a slump in the middle

Team Collaboration is Key

In innovation events were strangers collaborate, it is very important to allow for enough time to discuss expectations and what kind of skills everyone brings to the team, in order to make the collaboration effective. The Design Sprint methodology itself doesn’t address getting to know each other in the sprint team, so that was added as part of our event. The teams had some time and questions during the first day to get to know each other. As such, the team constellations were made ahead the event with the idea of having people from diverse backgrounds in the same team.

In hindsight, we could have done more for leaving some room in schedule to discuss things like Yes,and… thinking, which is very crucial for a fast moving process like a sprint. Yes, and.. means that it is important to try to build on others’ ideas and try to be a productive team member in moving the process along.

Technology May Fail

When you are working with a complex setup like a Remote design sprint with 8 different remote teams, issues with technology can either make it or break it. If there’s a team member who has issues with internet connection or is less used to working with digital tools, the event may become not accessible for them and highly frustrating.

For as, the major tech issue occurred with Mural. There’s a readymade template in Mural specifically made for Remote Design Sprints. We used the template with a few modifications of our own, copied for all the 8 sprint teams. The unfortunate news is that the template is too big and therefore becomes extremely slow, basically rendering the whole template unusable and driving the sprint teams mad.

We solved this by making individual Murals for the different days of the sprint for all the teams, which was a lot of work during the event. In our communication with Mural they have promised some improvements which should help, but as the time for our sprint those were not yet functional. Other than the slowness of the template, Mural was a very useful tool during the event, and easy to use for the participants.

Information Needs to Flow Uninhibited

In the Remote Design Sprint Guide Jake Knapp et al. recommend using Basecamp as a tool for information exchange during the sprint. We did not use Basecamp, and for document storage for the teams we offered OneDrive folders and the students also had access to a Moodle LMS environment.

During the event it became very clear that especially for a multi-sprint event you do need a very solid structure for information sharing between all parties of the event – now the sprint teams kept forgetting about the OneDrive folders and how to access them, the facilitators were not able to upload anything to the Moodle environment, and the only way to communicate with sprint teams outside of Zoom was emails sent by the project manager, and in Zoom the communication from and to breakout rooms is not practical. It would have been very good to have a communication and file storage channel that everyone would have been able to access with questions or updates, since inevitably there will be all kinds of changes and needs to share information during a complex event.

One useful practice that we implemented was to create one breakout room in Zoom for the facilitator team. There we had privacy to discuss tech issues or any other problems the sprint teams were expressing, instead of having those discussions in the main room in Zoom.

The Decider Role is Important

The Design Sprint methodology is originally created for a team inside a company to work developing A solution. In our case, the sprint teams were external students who had relatively little time to discuss their challenges with companies, though we did our best to include the company representatives in several phases of the sprint. There are specific phases in the sprint where a Decider role is applied to make a final decision about which solution will go forward.

We noticed that the teams which were able to discuss their solution with the company during the sprint produced ideas that the companies found more useful at the end of the sprint. So, if you find yourself in similar setup with an external team sprinting for a solution, do try to engage the client in every phase where a Decider is needed, even if it may seem unnecessary.

Final thoughts

The process of facilitating this sprint was intense – and also fun! The complexity organizing it virtually is huge, and as a facilitator you have to stay constantly vigilant to make sure everyone stays on board. There’s also lots of work to be done ahead of the event. During the event one of the teachers, who was responsible for creating breakout rooms described it as feeling like working in flight control. But when you manage to pull it off it feels great – I also got the feeling the companies got some valuable solutions to their challenges from the 8 sprint teams.

I would like to thank the organizing team Cecylia Kundera, Hanna Lumenkoski, Heini Heinonen, Henriikka Tikka, Michelle Sahal Estime, Pirjo Valpas and Teemu Ruohonen, Päivi Mantere and Merja Lahdenperä for this amazing experience and all the hard work, as well as the companies and students who participated in making this happen.

About the author