Hopefully your Enterprise Design Sprint will turn out perfectly. But life isn’t perfect so this post is all about troubleshooting tips for preventing and dealing with issues that might come up.
Equipment failures (and unexpected events)
There’s no telephone in the room, the fire alarm goes off, you lose internet, and key participants are stuck in traffic. All of these have happened to me in meetings.
Besides eating up valuable time, these issues can be stressful. How you respond can impact your reputation and the workshop experience for others. There are two solutions: prepare a backup and be flexible with the schedule.
Be prepared by bringing extra equipment like a phone, mobile hotspot, or portable flipboard/whiteboard to replace anything that could be missing or broken. Schedule the meeting in a building with backup conference rooms and check out the space ahead of time. Prepare both paper and digital versions of each activity. Think about how you could facilitate the activity in real time physically, in real time virtually with screen sharing software, or how you could email out materials ahead of time and send out updates after the activity.
Sometimes there will be delays that are just unavoidable. If you don’t have the right stakeholders available for an activity, shift focus to something else so that you can continue work in the short term and have the rest of the participants catch up later.
If you find yourself with less time than you planned, be aware of which sections you can cut or defer and which you can’t. Maybe you only have time to get to one customer group or just a high-level picture of the process. Deciding which pieces to cut down on will depend on how much your team already knows about each area. You should spend more time on areas that you have less info about to uncover new insights and questions. However, don’t cut out a step entirely. It’s much better to review only one customer segment in depth than to skip the customer understanding step completely.
You can’t get all of the participants in the same room
Agile recommends face-to-face interactions for better outcomes. However, remote teams (and especially remote subject matter experts) are the new normal. For one meeting our team traveled to the client site with all of our flipboards and post-its, ready for an engaging in-person design session. When we got there we found out that the majority of the stakeholders would be on the phone. We ended up facilitating the entire day-long meeting with Powerpoint slides and Visio.
If you have remote participants, a telephone with high-quality audio and a webcam will be key to keeping everyone engaged and informed. You know what’s it’s like to be on the phone for a one-hour call? Now multiply that by 8 over 5 days. Not so much fun. Having visuals to look at and worksheets to fill out can help improve the experience for remote participants. Many of the activities can be completed by sharing digital files so encourage remote participants to prepare materials ahead of time, fill out excel worksheets or snap pictures during the day.
You could also try delegating tasks where their remote status is an advantage. They could work on individual tasks to complement the group work like researching the answers to questions, sending out emails, pulling together existing documentation, or making a diagram based off of their own expertise.
It also helps if you’re clear about when remote participants need to call in and when they can take a break. Define a process for leaving messages to each other, either through the chat window in your screen sharing software, instant messaging, email, or text messages. There’s nothing worse that realizing an hour later that part of your team got cut out for a large chunk of the conversation.
If the team is taking a break or working silently then both verbally inform the group and leave a message for the remote participants. Write down “break until 11:05” on the slide you’re sharing, share it in a chat, and send out an email. They’ll appreciate knowing what’s going on so they don’t need to worry if they lost phone connection.
Can’t block off an entire week for the sprint
It may be difficult to convince people to block off an entire week of time for the sprint. Especially if it’s the first one you’re trying in your organization. Don’t be afraid to start with the time you have and gradually expand (or contract) to a full week. It’s better to gradually get closer to running a sprint in a week than to avoid it all together. Try running larger team sessions in 2-hour increments and getting a smaller group of people together for the rest of the time. Also, don’t be afraid to skip a day or spread it out over a weekend. I ran a sprint once when there was a holiday in the middle of the week so we did days 1 and 2 at the beginning, days 3 and 4 at the end of the week, a stakeholder review at the end of Friday and the users reviews the following week.
Lack of technical information
The impact of your sprint will be limited if you only have user experience and business representation. Technical information will be important when determining the complexity of a solution and creating a feasible roadmap. Deferring all technical analysis to the end of the sprint will cause delays in order to set up the meetings and share documentation. If you then need to completely change the solution and roadmap to account for current constraints, you would have lost the time that you were trying to save by running the sprint in the first place.
If your technical partner is a black box then you may need your technical team to spend some time learning about the partner architecture and technology before the sprint. Get the partner team involved as soon as you schedule the sprint, so they can be prepared and share information ahead of time.
Lack of key participation
You’ll probably get the most resistance from managers if you want to invite people who are resource bottlenecks. Your organization probably has some critical people where work can’t move forward if they’re not involved. That tends to be the technical team but depending on your work it could be a different role like testers or stakeholders. The bottleneck resource could change depending on where you are in the product development cycle.
It’s better to include the people who are the most knowledgeable about the work and/or will be executing the work. Not having the team executing the work involved could result in extra knowledge handoffs and lost information. If you need to make tough choices about the invite list, consider treating some resources as subject matter experts instead of participants in the entire sprint. One generalist who can recognize when specialists are needed may be enough to make significant progress.
Another tip is to make sure that you have manager support of the time spent on the sprint. If you don’t, you might have key participants pulled at the worst moments which can ultimately waste time and defeat the purpose of the sprint. Clarify to management when those team members are needed, why you need those particular people, and how the work will benefit the organization.
Low energy or lack of focus
If people are losing focus, stop for a break. It’s better for people to be focused than to push through an extra painful and unproductive 15 minutes. Encourage them to grab some food or coffee, walk around, chat, or check up on email so they can come back refreshed.
Varying levels of familiarity with design sprints and the design process
Experiencing the design sprint is the easiest way for new people to learn the process. It’s helpful to balance new people with those who have experienced the sprint or similar design processes before. If you do that then you’ll find your team members teaching each other. Peer training can be a much more effective learning and bonding experience than you lecturing about the entire process.
In any case, it’s helpful to run a brown bag or info session ahead of time where you can share information about the process, agenda, and why you’re doing each step. I also like to share a quick overview of the process at the beginning of the week to remind people how it will play out. Sharing this information up front can help people envision how they fit into the process and what will be expected of them.
Participants not pulling their weight
In my experience, participants are more motivated if you have a smaller group of engaged participants than if you have a larger group where it appears that some people are not working as hard or adding as much value. It can feel like they’re getting paid to just listen in or there may be jealousy if it seems like they’re answering emails instead of paying attention and contributing.
Sometimes the team will bring this up during the retrospective, in which case your team can talk it out. Otherwise, you may need to clarify with each participant what their role is and understand why they aren’t currently participating in each activity. It may be that they don’t fully understand what’s expected of them or don’t feel that they could add any value to the activity. If that’s true, encourage everyone to research the topic ahead of time. Remind everyone that even if they aren’t a designer, they can still come up with helpful ideas as customers and users of other products and services. On the other hand, it could be that the individual really isn’t a great fit for that particular topic in which case they don’t need to be involved in the sprint. Consider treating them as a subject matter expert or spread out their knowledge so that everyone involved in the sprint either provides valuable domain-specific or process-specific knowledge.
Results from the sprint are being ignored
You put in all of this work and have a good plan that was validated by others. And nothing happened with it. Your proposal just sits there or gets overturned by other priorities. There are a couple of ways to deal with this depending on the problem.
If the sprint was ignored because not everyone was aware of the sprint outcomes and the benefits:
Be sure to invite high-level decision makers to the sprints and encourage them to participate so they are aware of what’s happening even if they choose not to join. Then create a forum to share the successes and outputs of the sprint. Make sure that this is happening both upwards to management and downwards to the team members who weren’t involved in the sprint. Share the information directly if possible to avoid translation errors. Encourage sprint participants (from all groups) to share their findings as well. The more executives see that there is momentum behind something other than a white paper the more likely they are to support it. Note: It may make a difference who shares the message. For example, a business executive may be more willing to listen to the argument of someone from their company than someone outside of their company. Or the other way around might be more effective. Think about the dynamics in your organization when deciding.
If the sprint results were ignored because other changes were a higher priority:
Try to find out the reasoning behind the changes. Do other initiatives contribute more to strategic goals? Maybe your initiative truly is lower priority in relation to the larger mission. Or you may need to refine your business value pitch to make sure that the value to end users and the business is clear. If they are valuing short-term goals over long-term goals, try highlighting what the short-term actions are and how they will ultimately benefit the organization in the future.
If the sprint results were ignored because decision makers saw a “flaw” in the team or process:
This is not fun to think about but your sprints will not gain wider traction if you don’t address these concerns. Two things could be happening: a) they don’t see your team as the right group to solve the problem or b) they don’t see the process as being the right one to solve the problem.
For part a, figure out whose viewpoint you’re missing and either invite those people to be part of the design sprint or figure out what they know and their approach and integrate parts of it. It could also be that you haven’t built up enough trust with the decision maker. Building up a catalog of wins, and a reputation of delivering quality on time will help. Being unreliable will hurt. Try smaller scale sprints at first before working your way up to more complex or political issues.
An alternative reason is that they didn’t think that this was the right process to follow. Build up a list of case studies to show how the process helped to achieve business goals and solve problems in comparison to other processes that you were following. Encourage executives to candidly share their thoughts about the sprint so that you can gradually improve it.
If the sprint results were ignored because the work involved is difficult and requires managing dependencies and coordinating with others to make progress over time:
Sometimes the work needs to get done but we’re all wired to follow the path of least resistance. Reducing ambiguity will help move things along. Focus on your recommended next 3-5 steps and be clear about who is owning those actions. Create regular meetings for checking in, and set up knowledge management like roadmapping tools or a wiki for storing info. If you bite the bullet and take care of those items that don’t clearly fall into anyone’s job description, plus provide a clear set of action items and assignments, then all that’s left is to hand over the list to a manager to track progress.
If the sprint results were ignored because the work involves architecture runway or other infrastructure in place before it can be implemented:
If managing dependencies for business features can be met with resistance, architecture runway or other infrastructure work is even less likely to move because the value is not immediate. One way to help incentivize decision makers is to showcase how many business features would be possible once the architecture runway is in place. The aggregate value may help prioritize the work needed, especially if one single change may not seem worth the effort. As before, outlining the small steps and who needs to do them might make people more likely to take action.
Next steps
We got real about the types of problems you might encounter, especially if you’re trying to run an Enterprise Design Sprint in a complex and difficult environment. Hopefully, these troubleshooting tips helped you feel more confident about facilitating your own sprint.
You’ve learned about why Enterprise Design Sprints are useful, how to pick a great topic, what to do during and after the week, and how to troubleshoot common issues. The next post in the series will be about scaling Enterprise Design sprints.
Update: This blog series about Enterprise Design Sprints has been expanded into a guide for facilitators with all of the content, plus 50+ worksheets and some other surprises. Check it out in the store.
Related reading
- Why you should try an Enterprise Design Sprint
- How to pick a great Enterprise Design Sprint topic
- Day 1: Surveying the as-is landscape
- Day 2: Imagining a high-level to-be
- Day 3: Outlining a detailed to-be
- Day 4: Building prototypes
- Day 5: Reviewing with stakeholders
- From analysis to action: What to do after the sprint
1 thought on “Troubleshooting tips for Enterprise Design Sprint facilitators”
good site thanks for sharing
Comments are closed.