Sprint to comprehend and solve an unexpected problem

Sometimes teams hit problems that a) need to be solved quickly and b) are complex enough to require the collaboration of several members to solve. In a surprising amount of cases, teams can correctly identify the problem, yet fail to solve it in a timely manner. Teams require a strategy for comprehending the problem, then proposing and deciding on the best solution.

The goal: in two hours, move from identifying a problem to having a map of the problem and a storyboard for its solution.

The timeline will initially frustrate some team members who just want to get to solving the problem right away, but too often jumping right in leads to something like:

“I already know how to fix this, it will be easy!” (20 minutes later) “OK, there are some things I didn’t anticipate.” (40 minutes later) “Hmm, maybe I need to alter my initial approach.” (1 hour later) “I’m going down a rabbit hole, what was the problem again?”

To avoid this, we dedicate a significant amount of time up front to ensure that everyone understands:

1. The problem
2. The system in which the problem resides
3. How that problem impacts the user

This process below is an adaptation of the week-long process described in Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp. I highly recommend the book. It will give greater context and details to the steps I’ve extracted.

In order to compress days worth of effort to two hours, we have to meet some prerequisites; otherwise, the problem solving process will take significantly more time. There is no getting around that sometimes.

1. The right people are available to swarm the problem.
2. At least two people can correctly identify where the problem is.

The first requirement means that team members with the appropriate skillset can be taken off other work and dedicate their time exclusively to this problem. The team should be between five and seven people, and must collectively have the expertise to map out the story and implement a solution. Ideally, this team is in person. Remote members can video in, but they can’t be splitting their time with something else and just intermittently checking Slack.

The second requirement is that the location of the problem is already correctly identified. The exact size and shape of the problem can — and probably will be — unknown. But the general nature of what is going wrong needs to be understood. If nobody knows what is going wrong, use other strategies to get a hold of it, and then come back to this one.

The strategy

The strategy has three phases: Comprehend, Propose, Implement.

Comprehend

The first phase is all about understanding how the problem impacts the user. Comprehending the problem in this context makes selecting a target easier, and increases the likelihood that the outcome is an actual improvement to the user.

Set the stage by getting the team together, collecting materials, removing distractions, and identifying key roles. These roles are Facilitator, Decider, Scribe. For technical teams solving technical problems, the Decider should likely be a team lead, rather than a manager. Level expectations that building will not begin until the best solution is fully mapped out.

Begin with the end by stating what the user should be able to accomplish. This is the end result that this problem is preventing. Write it on the far right side of a whiteboard.

Map the user-centric story on the whiteboard, ending with the user accomplishing the end goal. This is the most critical step of process, and it should take as long as necessary. Technical teams will want to default to architecture diagrams, but keep them focused on the process the user goes through. Once there is a shared understanding of what the user is experiencing, then pull up architecture diagrams from documentation and draw connections between what problem the user is experiencing and what component of the system is causing the problem. This approach ensures that the immediate problem is being addressed, rather than being distracted by tech-debt-closet-skeletons.

Pick a target to attack. A thorough map should make this decision straightforward, but sometimes team members will disagree on exactly what is causing the problem. In this case, each team member put a star on two places on the whiteboard where they think efforts should focus. Ultimately, the Decider needs to either pick a target or send the team back out to better identify the problem.

At this point, the team has spent about an hour coming together, mapping out the problem, and deciding on a target to solve. The next hour will focus on producing options and selecting a solution.

Take a five minute break.

Propose

Now that the team comprehends how the problem impacts the user and has selected a target, it is time to propose solutions and select a single solution to implement. If the people in the room don’t have the expertise to address the target, consider bringing in another member. Just make sure they understand the user story before you move forward.

Instead of shouting out ideas, work independently to make detailed sketches of possible solutions. Group brainstorming is broken, but there is a better way.

— Sprint

Crazy 8’s is a sketching exercise where each person takes a sheet of paper, folds it in to eighths, and spends one minute putting a solution to the problem in each square. Each iteration should improve upon the idea. If you can’t make more improvements to an idea, move to a new one. Sketching can be uncomfortable for some people, but the individual deep work is far superior to unproductive brainstorming. Rather than allowing the loudest idea to win, these sketches enable each team member to produce a viable idea.

Detailed sketch the best idea from Crazy 8’s on the back of the sheet. Spending adequate time here allows each team member to think through details of their solution and identify potential pitfalls. Make an exception to the no-devices rule and encourage research to complete the sketches. The drawings don’t need to be pretty, but the idea should be able to stand on its own without narration.

Art museum is a time for silent review of each sketch. Encourage each team member to take notes about what seems promising and what challenges might arise. Have each person mark the two solutions they think are best.

Discuss the pros and cons of any solutions that received votes. The Facilitator should manage time and work to make sure quieter team members voice their opinion as well.

Decide on a solution. The Decider does this, plain and simple.

Storyboard this solution. Going back to the original map, what does the new flow look like for the user? Only after considering impact to the user, begin to break down the technical details of what needs to happen.

At the end of this hour(ish), the team has come up with multiple potential solutions to a problem, collectively discussed the best options, the Decider has chosen a solution, and the team has adjusted the user-centric map to accommodate that solution. The next stage is implementation.

Implement

Having mapped out the chosen solution, it is now time to implement that solution. The stage doesn’t end until the solution has been tested, incorporated, and documented.

Build the solution using your team’s normal workflow. Depending on the complexity of the problem and solution, this may take hours or days. But keeping team members dedicated to this single problem and not distracted by other tasks will help it go more quickly.

Test and gather feedback on the solution. This is especially important if the user is aware of the the change! Iterate as needed until the problem is solved.

Document for future work because it is likely this solution is imperfect due to time pressure. Keeping the lights on with an imperfect solution may be acceptable now, but dedicated time in the future to produce a more permanent solution so the problem doesn’t rear its head again.

Start to Finish

Comprehend

1. Set the stage (10 minutes)
2. Begin with the end (10 minutes)
3. Map a user-centric story (30 minutes at least)
4. Pick a target (5 minutes)

Propose

1. Crazy 8’s (10 minutes)
2. Sketch (20 minutes)
3. Art museum (10 minutes)
4. Discuss (10 minutes)
5. Decide (2 minutes)
6. Storyboard (20 minutes)

Implement

1. Build
2. Test and gather feedback
3. Document for future work

The first few times your team does this it will take a bit longer because the steps will have to be taught and people will have to overcome any skepticism to the process. Consider taking a known, non-urgent problem and solve it with this process as practice.

As you go through the process, keep track of any good ideas on a separate whiteboard. Communicate that they can be circled back to later. Jotting them down allows team members to feel heard and keeps the discussion moving on topic.

Conclusion

With complex systems, unexpected problems will always emerge. With this modification of a 5-day Design Sprint into about 2 hours, your team will be able to comprehend the problem, propose and select a solution, and implement a fix.