Problem Solving with Impact Mapping

In his book Impact Mapping, Gojko Adzic explains a way development teams and business stakeholders can collaborate to quickly identify alternative paths to deliverables that provide the best return on investment. Teams can construct a roadmap that helps them quickly learn whether a particular approach will produce the desired results and adapt to inevitable changes by answering the following questions: why, who, how, and what?

Impact mapping takes a lot from other brainstorming and planning tools, such as mind mapping and story mapping. I find that it gives a simple, structured way to focus on the purpose of what you’re trying to plan.

I’ve been experimenting with adapting impact mapping to help software team members identify problems with their agile software testing that they’d most like to solve, and brainstorm small experiments to improve in those problem areas. In my experience so far, creating impact maps is proving to be a great technique for problem solving.

In the first part of this two-part series, I’ll give an overview of how to create an impact map. In Part 2, I’ll help you organize your own impact mapping workshop, adding additional examples and instructions.

I recommend reading Gojko’s book—it’s short, and mostly pictures!—and the technique is simple; it just takes a bit of practice to get the hang of it. Here’s what I’ve done in workshops, and participants have come up with creative ideas they might not have thought of otherwise.

Why?
I think it’s a human tendency to start off any quest for a solution with an idea about what to do. This happens with software features too. Our stakeholders come to us and say, “Give us a UI that does X, Y, and Z.” They often want to give us the implementation, despite the fact that they hired us because we’re the ones who know how to develop the software.

When customers do this, it’s important to ask them the following questions: “Why do you want this feature? What business problem are you solving? What value will it add? How will we measure whether it was successful after we release it to production?” Once we understand the purpose, we can apply our own technical and domain knowledge as well as our creativity to come up with the simplest effective solution.

When it comes to improving how we develop software, including how we test and code it, the same technique applies. Resist the urge to start with deliverables and ask yourselves, “Why are we here in this meeting? What do we hope to achieve?”

In his book, Gojko suggests using “SMART” goals to answer the question “why?” This is a tried-and-true technique, nothing new—but how often do we remember to make our goals “Specific, Measurable, Action-oriented, Realistic, and Timely”? (There are several accepted variations on this, per Wikipedia). For me, thinking about how to measure success is key. And it’s important to remember to do that measuring once we try implementing a path to improving on a problem.

Write each goal on a sticky note, and put them on the table or wall space around where your group is working.

Here’s an example of looking at the question “why?” My team was delivering user stories for a particular epic, but most of them were being rejected multiple times. The developers weren’t getting the full and correct requirements for the stories, so there was constant churn. My tendency was to say, “We need to do ATDD so the developers understand the requirements better.” But this is starting with the question “What?” It would be better to set a goal such as, “Let’s reduce the number of rejected stories by 20 percent over the next two months.” Once started, this process generates many goals for improvement.

Who?
The next step in creating an impact map is to think about who will help us achieve our goal and who might be in our way. Are there people outside your team who can help? Going back to my example goal, reducing the number of rejected stories, perhaps we need to shorten our feedback loop by having our continuous integration builds finish more quickly, but we’re lacking necessary hardware. We might need our CFO’s approval to get money budgeted for that.

Think about people with whom you don’t normally collaborate. Marketing folks can give us great information about what’s most important to customers, which can help us budget our time appropriately. Customer support and operations also have information that’s valuable to us. Sometimes people don’t know we even need help. I remember when our team got the idea to have an impediment backlog, and we put “slow test environments” at the top. Our database administrator (DBA) and our system administrator were not even aware of our problem, and they quickly found and set up new, faster servers for us.

Gojko recommends filling in this template: <someone> can help us achieve our goal by <doing something differently>. Make the <someone> specific. Think about who is limiting your options. Can someone stop your team you even start?

Write each “who” on a sticky note, and arrange these around your goal. This is the second level of your impact map.

How?
For each “who” you identified as a help or a hindrance, specify how each person’s behavior should change, how he can help achieve the goal, and how he can be an impediment. These are the impacts—the desired changes that will help your team succeed with your goal. If we’ve identified the CFO as someone who can help us, approving a purchase or putting money for what we need in the budget is the impact. Getting help from marketing or customer support may be as simple as setting up a meeting or a schedule to pair with them.

Your impact map will help you visualize who creates an impact, and how that contributes to the goal. You may not choose to work with all the actors you identify or get them to do all of the impacts, but the map helps you see all the alternative paths toward achieving your goal. These provide the basis for small experiments to incrementally improve on your problem area.

What?
In Gojko’s impact maps, the third level answers the question, “What can we do, as an organization or team, to support the required impacts?” When you use an impact map to come up with possible software products, these are the deliverables—the features themselves and organizational activities. On an impact map, each deliverable is in the context of the impacts they’re supposed to support.

Using impact maps to help solve problems, our “deliverables” are the small experiment we will try to achieve the impact that will help us solve our problem. If we want the CFO to approve a purchase or budget change, we need to put together the case we will present to her to get her buy-in. For my example, we may decide to quantify the technical debt our “story rejection churn” is incurring, because money talks to CFOs! A deliverable could be a necessary training course for the team to learn how to use a particular test framework or time budgeted to collaborate with business analysts to get more complete requirements.

In my own experiments with impact mapping, I found the question “What?” is the least important level, which Gojko also notes in his book. Thinking about the people who can help or hinder us, and how they can do that, is the real spark for creative ideas to approach a problem.

Figure 1. An example of an impact map.

Get your team together to talk about which problems you need to make smaller. Pick the one causing the biggest pain (dot-voting works well for that), discuss why you want to solve that particular problem, and write SMART goals around it, Create your own impact map. Once you’ve added your “why” in the form of goals, start brainstorming about who might be able to help you meet them or get in your way. For Part 2, we’ll walk through how to do your own impact-mapping workshop to create lots of little experiments your team can try to chip away at its most intransigent problems.