Winded by Design Sprints
Originally posted on Ant.Cat
I love when groups get together and collaborate, but please try to avoid making the same mistakes our team did… It only leads to the group becoming drained, wiped-out, and winded.
TL;DR: Design sprints are amazing, but they aren’t magic. After 5 years, 50 design sprints, and countless ideations for tech, HR, and financial firms, I’m worn out by companies misusing them. The worst thing a product team can do is get stoked about a new sprint process, run five of them back to back with the same team, and burn them out in the process. Below are 12 things a team can do to get the most of their sprints.
A little background: What is a design sprint and what is the typical process? Google Ventures does a great job breaking it down: http://www.gv.com/sprint/ or buy the Sprint Book by Jake Knapp, John Zeratsky, and Brand Kowitz
When design sprints rock.
Be clear and concise about what you’re trying to solve. Design sprints are not designed to solve world hunger, one giant problem. They’re designed to focus on one specific piece of a big problem and optimize it.
We did this by leveraging “How might we…” questions to break down our big (world hunger) problem into bite-sized chunks. Then we focused on solving only one of the questions during the sprint.
“How might we…” questions are a helpful way to frame the problem at hand and move the team in the same direction.
For instance, How might we… (in regards to the massive problem of world hunger)
- … inform the public that world hunger is a real problem? (marketing and messaging)
- … get excess food to the people who need it? (logistics and distribution)
- … work with partners that will provide the food? (sourcing)
- … etc
Bring the real voice of your customer into the room.
Before the sprint, set up a time for a customer or two to chat with the team during the beginning of the sprint. Ideally, the chat will take place after the team has figured out what part of the big problem they’re trying to understand. This can be a video call, phone call, or in person interview that the whole team sits quietly and listens to while a facilitator asks questions. The goal is to gain empathy, and understand how the customer’s world works today.
My favorite question to ask during a customer interview is, “If today was my first day on the job, how would you train me to do this part of the job?” It puts your customer into teaching mode which gives the team a whole new view of the problem.
Constraints are key.
Many of the workshops we ran were left wide open with little constraints for the sprint participants. Our hope was to open up all ideas. It didn’t work. Participants often times froze and the ideas that came out fell flat most of the time. It’s like handing someone a blank piece of paper and saying, “Draw me a picture.” Instead, give them some lines and dots on the piece of paper and a mission.
What types of lines and dots can you create to help participants solve the problem? Maybe ask them, “If we only had a week, how would we solve it?” or “How would another company solve it?” or “If smartphones didn’t exist, what would you do?”
Keep everyone present.
Context changes are your absolute enemy. It’s rare to get a dedicated team together to give their full attention to a single priority. Treat this time as sacred. Starting the sprint a little later in the morning, like 10 a.m., gives people the space to get life/work in order so they can focus on the rest of the day.
Let participants design ideas alone, but share as a team.
The book Sprint by Jake Knapp, John Zeratsky, and Braden Kowitz talks about giving people personal time to work by themselves. This was my biggest takeaway from the book and it created the most dramatic and positive results from our workshops. The ideas were thoughtful, more complete, and gave everyone a chance to contribute.
When they suck.
Here are the top ways to burn your team out on sprints.
When the wrong users/customers are tested at the end of the sprint.
Reach out to an array of potential users/customers the week before the sprint and tentatively schedule them to demo the solution at the end of the sprint. Set the right expectations that it’s tentative and their participation would be invaluable. After the first day, when the problem is defined, check your interview list and make sure your potential testers match what you’re looking for.
If the team still feels they demo’d to the wrong users/customers, run the demo again the following week with a new cohort.
When the team can’t be together for the whole week.
Break the sprint into three parts, but don’t feel like you have to run all the parts back to back. Each part can be scheduled separately to find a time for everyone to participate.
Example:
— Part 1 — Defining the problem
— Part 2 — Prototyping
— Part 3 — User Interviews (In my opinion, this is the piece you want the whole team together to experience live. It brings life back to the team.)
When the group leaves without a final recap of the week.
Be sure to do a recap with the whole group, get them to share feedback, and determine your next steps. Take lots of pictures during the week, bring them out at the recap to help people remember what was covered.
When the team has no clue how the results translated to a change in the company.
Treat the sprint team like internal customers. Update them continuously as the product is developed or the problem is solved. Keep them informed and encourage them to advocate for the sprint process. Nothing sucks more than time wasted.
When the team feels like they wasted a week of their time.
Set up parameters that are very clear about what it will take for a successful sprint. Success is learning that what is being tested is either right or wrong…anything in the middle is hard to move forward with. Avoid flowery language.
When the facilitator overlooks the little things.
Don’t miss the care and feeding of the team. Be an amazing host. It’s a mentally taxing week. Provide healthy snacks and lunches to keep people moving. Check-in with the team before moving on to new pieces of the agenda. Make sure everyone is on the same page. Questions such as “What’s your biggest concern at this point?” will help bring out a candid conversation.
When it’s the same team, same process…over and over again.
Stop running the same team through the same sprint process over and over again. Change up the problem, add new unexpected teammates that would not typically be involved, like customer support, and try new things in the sprint process. Here are two great books for collaboration exercises: CTRL + SHIFT and Gamestorming.
To wrap-up, team collaboration is an amazing tool and my favorite part of what I do. Don’t give up on the process, keep the team working together, try out new processes, and avoid being winded by sprints.
P.S. here’s a quick tip on remote user interviews:
For remote testing we’ve used Lookback.io. Great product, but enterprise users may have restrictions on the types of Chrome plugins they can install. Webex is your answer if that’s the situation. Have the user share their screen, and turn on their video. The session can be recorded for the rest of the group that couldn’t attend. Also, be sure to have at least 30mins between interviews to give the team a chance to recap and get some notes down.
