It is now entirely possible to run a Remote Design Sprint in 2019 (+2020)
How to get started running remote design sprints with a distributed team
Some of the best work I’ve ever done has been with a remote team. In 2013, I worked with a back-end developer in Barcelona to create a fully working minimum viable product in just a couple of weeks. I did the design and the front-end and he would tie everything up in the backend.
It was perfect because we were both skilled at what we did and if anything, being distant location-wise helped us concentrate while in comfortable surroundings.
Fast forward to 2019, and I’m now a product designer running design sprints at Etch Sprints. I also train others to run design sprints. I believe in the power of teams collaborating together, packaged in a way of working that any team can use.
What changed for me
In February of this year, I was contacted by a company wanting to learn how to run design sprints. The challenge? Three candidates for the training in the U.K. and three in the U.S. Flying three of them to one location would have been expensive. The other alternative was for me to do two sets of training with a flight — also an expensive way to get them on board with the Sprint.
But that wasn’t going to solve the problem. These six people would be running sprints across their distributed teams globally. What they were really asking for was remote design sprint training to enable them to run remote design sprints.
Added to that the possibility of rolling this out to over 80 of their offices around the world for both internal and client-facing Sprints, we really had to nail down what this looked like for a distributed team.
Here, I’m going to share some ways of getting started with virtual design sprints.
I’m not going to say remote is better than in-person. The fact of the matter is that both work. Many successful companies use entirely distributed teams. Basecamp is one example. InVision is another:
InVision is a completely distributed team of 800, and they’ve still managed to hit unicorn status with a $1.9 billion valuation and see $100 million in annual recurring revenue. Something is clearly working there. ref
What is the Design Sprint?
The Design Sprint is a week-long step-by-step process for answering critical product and business questions through design, prototyping, and testing ideas with customers.
Developed at Google, and then GV, it is the best of business strategy, innovation, behaviour science, design thinking, and more — packaged into a way of working that any team can use. The methodology was described in the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp with John Zeratsky and Braden Kowitz.
I’ve personally run over 40 Design Sprints to date and am well versed in the updated 4-day method.
The challenges of working remotely
To start applying the Design Sprint methodology to distributed teams, first let’s recognise some of the unique challenges it presents :
- the need for effective communication
- some technology limitations
- working over different time zones
- the possibility of low engagement
Each team (including yours) will have a different set of constraints to work around. Effective communication and technology isn’t that much of an issue with the setup of the Sprint and good WiFi.
Time zones is an interesting challenge. What you’ve got to think of is tasks and outcomes, not hours. And with low engagement:
One of the most common issues with distributed (and remote) teams is this question: How will I know my team is working? The answer to this question is very simple: You don’t and it doesn’t matter. You could have someone working next to you in an office and they could still be doing nothing. ref
With those challenges overcome, what are the opportunities?
- working with the best people, no matter where they are
- potential lower cost of office rent and travel
- fewer constraints to enable scaling up
Now that you’re primed, how can we apply remote working to the Design Sprint? I’ve included three key points to help you get started.
1. Play the timezones
When asked to run our first virtual Design Sprint, we had to consider peoples working time. With three people in the U.K. and three in the U.S, the time difference looked something like this:
- St Louis, Missouri, USA = 8:00am
- London, UK = 2:00pm
With a bit of moving around, you can achieve a maximum of four hours together time:
That’s way less time together than the in-person Design Sprint, but then there’s the potential to use the other time available for asynchronous activities.
Hang on, I’m getting a little ahead of myself. Let’s just define what that means:
- asynchronous = time apart
- synchronous = time together
So now we understand our times, let’s take a closer look at the activities we need to complete.
2. Adjust the Design Sprint
Before we jump into the specific activities, you can get more familiar with the four-day Design Sprint (our preferred arrangement) over here.
You could spread the sprint out over a couple of weeks, but I really think you start losing the momentum of using the team’s short-term memory and the magic of giving yourself a time-boxed period to make decisions.
Instead, start by splitting the activities in what has to be done together (or synchronously) and what can be done apart (or asynchronously). We’ve found the following works right now, but with more repetitions, we may find a better version:
Day 1
- Ask the Experts and How Might Wes (30 mins)
- Long-Term Goal and Sprint Questions (30 mins)
- Map (45 mins)
- Lightning Demos (30 mins)
- Four Part Sketch (60 mins)
That’s 3.25 hours of pure activity time. Add in a few breaks and you’ve got just over 4 hours.
Day 2
- Heat Map Vote (20 mins)
- Speed Critique (30 mins)
- Straw Poll Vote (5 mins)
- Decider vote (5 mins)
- User test flow (30 mins)
- Storyboarding (1:30 mins)
Again, add in a few breaks to the 3 hours of pure activity time and you’re looking at around 4 hours work.
We do Day 3 and 4 as usual at Etch Sprints, having the facilitator and designer create the prototype and then joined by the decider and the rest of the team in observing in user testing. You could tag-team design and user testing if constrained by synchronous time. User testing remotely is actually how we do the far majority of our in-person Design Sprints.
Try not to just lift and shift
Ok, so we can fit the workshops in the synchronous time together — great! But there are some problems here. Remote will fail if you just try and replicate what you do in-person. So consider these points:
- in this example, the US team are have the advantage of creating in the morning, but the UK team have the afternoon slot, which could be harder to concentrate in
- we have also not considered breaks — called “pressure-release valves” in Sprint
- lunch too is omitted, but the could be done either before or after the days activities
- we also need to communicate more when not in the same physical space
There are also signs of opportunity. In this setup, the London team could do the four part sketch on the morning of Day 2.
There are other ways of adjusting the Sprint for remote, but this should offer some ideas to get started.
3. Choose tools to help
It’s 2019 and technology has caught up with ambition. Modern tools are helping teams all over the world get their work done, and they really come into their own when you’re not sitting next to your teammates. You can pick and drop any that you find useful, but here’s our current selection:
- Mural — for ideas, deciding and voting
- Figma — for prototyping in the cloud
- PingPong — for recruitment and user testing
- Zoom — to video conference
You can use others tools to help sure, but be aware that adding more tools to your toolbox can often make things more complicated and take longer, as people try to find for artefacts or where the decisions were documented.
This is just a start
I have found that it is often better to run before you can walk. This is just a first step, but I’m excited at the potential to bring the Design Sprint to distributed teams and fulfil the original mission of the Design Sprint of being a way of working that any team can use.
There are many more improvements to make, and over the coming weeks I would like to understand:
- do we need to alter the activities?
- is there a minimum and maximum of together time?
- is there a case where it’s impossible to run a remote Design Sprint?
- what could be special about the remote Design Sprint?
- how can new teammates on-board
- what health and wellness considerations need to be taken into account?
Doing reps (repetitions) of the Remote Design Sprint will tell us more.
Like this and want more?
- tune in to the Etch Podcast 🎧
- subscribe to our email newsletter 💌
- we also love Instagram 🖼
Ross Chapman is the Head of Etch Sprints in London, UK.
He has run an extensive range of Design Sprints with product teams and brands to solve business problems within four days, getting teams working faster and better together.
