4 Ways to Make Your Discovery Sprint Better

Last year at the height of the pandemic the Department of Defense’s Joint Pathology Center started work on what it’s calling the largest repository of pathological samples in the world. This entails uploading data related to more than 55 million slides and tissue samples. The scope and complexity of the project was daunting, so its leadership decided it would launch a discovery sprint -- a one or two week intense deep dive into a problem to develop recommendations and a plan for solving. While discovery sprints originated in Silicon Valley, organizations and nonprofits such as the DoD are seeing solid results from it, too.

Discovery sprints are led by small teams of designers, researchers, technologists, and those invested in the problem of practice. During a sprint participants identify the problem, interview those affected by it (for instance, those assigned to work on it at all levels as well as end users), research various solutions, develop a process or plan to solve the problem, lead another round of meetings with interested parties to get buy-in, and then present the solution to those who will execute on it. I recently had an opportunity to support an organization’s project related to bringing broadband to underserved communities. It came about as a result of a sprint.

This project directly aligned with my background, expertise, and interests and seemed very straightforward. However, no plan is ever perfect, and -- once I started rolling out the solution we had agreed upon -- I found holes that needed plugging. While I firmly believe that discovery sprints are a smart way to investigate a problem and pose realistic solutions to it, there’s always room for process improvement. Below, find the lessons I learned about my project and how we could have improved the preceding sprint.

1) Give sprints and projects a human-centered approach.

As the Centers for Disease Control explains, a logic model is, “a graphic depiction (road map) that presents the shared relationships among the resources, activities, outputs, outcomes, and impact for your program. Sometimes called human-centered design or user research, logic models depict the relationship between your program’s activities and its intended effects.” In practice, this involves identifying a problem of practice, proposing a theory of change, and listing all inputs, outputs, and outcomes when the theory is put into practice. It can be tedious, so it should be approached as a team with representation across multiple verticals. That said, when an organization or nonprofit uses this tool as part of their discovery sprint, it is critical to also ensure input and participation from anyone who will be impacted by or work on the intended solution.

During the discovery sprint, end users were part of the investigation and definitely considered in the proposed solution. Despite our best efforts to bring key groups together to work towards the proposed solution of ensuring communities had home connectivity and access to digital literacy training, the process wasn’t working as we had planned.

2) Be prepared for things to change.

All of the planning and preparation for my recent project leveraged some incredible networks the organization had built and had access to. Yet when it came down to it, it simply didn’t matter. We were unable to get movement in the ways we imagined and hoped we could. We had to take the huge step of having a critical conversation and acknowledging our desired plan and outcome wasn’t going to work. Once we accepted that outcome we were able to explore options and continue working towards connecting families and communities with home internet access.

We’ve all been in situations where things don’t go as planned. That meeting was one of those moments, and it was disheartening to say the least. We thought we had the right players, the right process, and the name of the organization to drive change. Instead, we stripped the plan and had to go back to the basics.

3) Sometimes you just need a one-pager.

When I embarked upon our broadband project it made sense to me and to those closest to it. However, when we tried to briefly talk about it with the stakeholders -- think elevator pitch -- it was much more complicated than we initially thought. We realized that not everyone understood the problem, or our ideas for solving it. As we thought about how to fix this problem, the idea of a one-pager came up. Yes, this vehicle is often overused in the land of policy shops, think tanks, and nonprofits, but sometimes it’s exactly what you need.

We started by combing through the information gathered during the discovery sprint and augmented it with newer information collected during our months of meetings with various groups. From there, we summarized and synthesized, identifying the why as well as our ongoing efforts to address the problem and potential next steps. We took everyone into account -- the organization’s staff, policy makers, and external parties who could possibly help.

Looking back on the project and these three crucial steps, it’s amazing to me how much our solutions that came out of the initial sprint changed. I realize that it’s okay, though!

4) Be open to alternative solutions.

A sprint may identify one type of solution, but keep an open mind. Sometimes, even the best laid plans go sideways. This happened during the project I recently completed. The sprint dictated that one of the stakeholders would perform a specific task. After reflection it became clear to us that wasn’t the best course of action. In the end, the stakeholder contributed money rather than time and effort. While it wasn’t what we expected it worked out nonetheless.

Looking back on these lessons it might seem like discovery sprints are less-than-successful, but this couldn’t be further from the truth. My role as a public interest technologist is to support projects where a specific skill set can be applied to support and solve problems. However, as my experience shows, it wasn’t until I took inspiration from my time as a classroom teacher (when I made constant on-the-fly adjustments to a student’s learning) that I saw real success. For this very reason, I will go into future projects with an agile mindset since I see how important it is to roll with changes when they need to occur. I’ll be treating sprints a little more like a marathon. Slow and steady will win the race.