How to make your first Design Sprint a success
Over the past couple of years I’ve facilitated and participated in more than a dozen “Design Sprints”. These are week-long bursts where a small team of people come together to solve a specific business problem. They’re exciting, fulfilling, exhausting and incredibly effective when they’re done well.
(If you want to know more about Design Sprints, you can read Google’s excellent description).
Because the approach is relatively new, a high proportion of the Sprints I’ve worked on have been the first ones an organisation has run. Like any new method that gets tried out that’s meant there has been a steep learning curve, and things haven’t always gone as well as they should. That’s normal and all part of the process of learning.
I’ve learnt a lot from these sessions. Some of these lessons are unique to the organisations I’ve worked with, connected intimately to their culture and operations. Others are wider reaching that have cropped up several times and are worth highlighting.
It’s this latter group I’ve pulled out. Don’t think of this as a definitive list, or a collection of critical success factors though. They’re more a “starter for 10” to get you thinking and I’d love to read what you’ve learnt in the comments.
A Design Sprint doesn’t “just happen” – it gets planned
It can easily take a couple of weeks to prepare a Design Sprint. You need time to find and collate the right data, an appropriate room needs to be booked, diaries have to be coordinated. If your organisation isn’t used to working in an agile or lean way you’ll need to negotiate.
This latter one shouldn’t be underestimated. Taking someone out of a team for three to five days is a big ask and can be quite disruptive to small departments. Senior management might be committed to the approach, but it’ll be line managers who can easily turn things on their head. One example I dealt with was a participant who didn’t come back from a break after being hauled out for a “monthly performance review”. It broke the flow and the participant came back demotivated.
If you can avoid the “just do it” approach to gaining access to people do so. Better to sell the benefits of what’s going on and the importance to the individual, team and organisation than have someone in the room whose line manager is resenting being told to do something.
The room matters
You need a big room. I can’t stress this enough, but I have spent too much time in rooms that are a little too small for what we’re trying to do. The result is work has to be brought down from walls so we lose sight of it, people trip over one another, the air turns stale and the temperature rises.
If your room looks like this you need a bigger room. (Credit to TokyoForm)
You also need a room with walls you can put things up on. One room I found myself in had a “nothing on the walls” policy as they didn’t want to have to redecorate when the lease was done. We got around the problem with static sheets that clung to the wall and we could put our post-it notes and Blu Tack on.
The final thing to bear in mind is you can run these off-site if the room issue is insurmountable, but I prefer to run them in the business. This can create a bit of a stir, which helps sell the idea and it’s easy to invite stakeholders in at various points. Little is more effective at selling the idea of a Design Sprint than having the CEO walk around and seeing how you got from “we have a problem” to “this is a viable solution”.
The facilitator should be independent of the team
Yes, I am a freelancer, but no, this isn’t a pitch for work (but feel free to hire me!) The facilitator should be focused on the process the team are working through; keeping it running on time and adjusting as dynamics dictate. This becomes more difficult if they’re down and dirty with everyone picking problems apart.
The second benefit to having an independent is they can challenge the room more easily. Their challenges won’t be seen as “defending my ideas” and the helicopter view they’re bringing can snap everyone out of group think.
One of the earliest Design Sprints I was in had the sponsor facilitating. After three days we’d effectively rubber-stamped their pre-conceived solution as every challenge and new idea was systematically knocked down. It was the first – and last – design sprint that organisation ran as it was seen as a waste of a lot of people’s time.
Be a bit flexible.
There’s a process that the Design Sprint moves through. It’s there to guide the team’s activities as they understand the problem, generate ideas, agree the solution and build something to test it. There are activities that take place at certain times and which last for specific durations. Which is fine.
Sometimes the room goes in a different direction and it’s the facilitator’s job to manage that. Although the general flow shouldn’t be disturbed, adding or removing exercises, adjusting timings and sometimes letting things drift a little are necessary to get the job done.
I had a team ask to repeat an exercise as they were struggling to find consensus. Rather than repeat and expect a different outcome, I inserted one of my Lego games first to snap them out of their current way of thinking, then tweaked the end of the exercise. A bit of flexibility got them past their blockers and into consensus.
There are probably going to be two types of people watching what happens. The first wants it to be a success, the second doesn’t. In both cases you need to be aware they may try and populate the Design Sprint with “their people”.
If this is your view of the workshop – RUN! (Credit)
The point of a Design Sprint is only the people who need to be in the room are in the room. They all have a specific role to play and they’re there to actively contribute. This is why teams tend to be 4 to 6 people in size (plus the facilitator). More than this and roles become diluted and dynamics difficult to manage.
Although sponsors may want to add people to the team to help with selling the idea into the organisation it’s got to be resisted. Keep politics out of the room and focus on creating a successful outcome. Little is more effective politically than success.
Clear the diaries
There’s a big time commitment associated with a Design Sprint. UX designers can spend a week working on it, product managers longer and even people who are “just” participants are going to spend 3-4 days in a room. Some organisations find this daunting.
What you can’t have is a revolving door where people enter and leave the room based on their availability. Someone who spends a couple of hours at a different meeting, or who can only turn up for 2 days isn’t someone who should be involved. Their presence disrupts the flow of ideas, means someone’s playing “catch up” and damages the process of building consensus.
If you have to push it back by a couple of weeks to get diaries blocked that’s way better than doing something early and already being set up to fail.
Know what comes next
A lot of focus is going to be on “doing” the Design Sprint, which is perfectly fine and natural. Just like you’ve spent time planning how the Sprint will happen, you also need to plan the “what happens next?”
Probably not the right reaction to the “What happens next?” question. (Credit, me!)
My preference is to use the output as the starting point for a real project using whatever process is in place. Sometimes this has meant building a business case through some more detailed business analysis and design. Sometimes it’s fed straight into “Sprint 0” of an Agile development process. Once or twice it’s sat on a shelf for people to look at and recall “the fun we had” because deciding it’s an approach that’s not right for the organisation is a valid decision to make.
Whatever the next steps make sure they’re understood in advance and everything is lined up to make it happen. Being able to demonstrate how the output flows into the rest of the business is a powerful message that will get noticed once the excitement has died down.
Are there more lessons?
Every day of every Sprint you should be running a session to capture lessons that you can use to make the next day and the next Sprint better. A typical team can easily generate 50 or 60 individual ideas across half a dozen themes. Of course, ideas are one thing, being able to put them into practice the next time round is another.