How Impact Mapping Gives You Multiple Options to Pursue

In “Problem Solving with Impact Mapping,” I explained the basics of impact mapping, starting with the “whys”—the SMART goals your team wants to achieve. For each goal, you identify who can help or hinder your path to the goal, how each person will help or hinder, and what they can do to help you along. Since you’ll come up with multiple “whos,” you’ll have several alternative paths to consider.

Try Something Out!
Mapping out several branches that start with a “Who” and flower into “How” and “What,” you now have lots of places where you can try improving on your problem area. Resist the temptation to “fix” everything at once. Use dot voting or a similar technique to identify the top one or two problems to tackle. Take the sticky note for your top goal and start creating your impact-map skeleton.

Once your map is done, choose one or two paths for a small experiment. Gojko Adzic’s book Impact Mapping encourages us to think about the simplest way to support each activity. So, how can we test that the assumptions we made are correct?

One of the advantages of impact mapping is that it gives you multiple options to pursue. They provide “real options” that help us take a more direct path to our goal. Each option has value, but some may expire. We should keep our options open as long as possible, in order to adapt to changes.

Getting our CFO to enable us to buy new hardware is a great option, but what if the company has to freeze the budget for some reason? We’d better have more options ready to go. Perhaps we can reduce story rejections by having the programmer working on a story pair with a tester to go over the story requirements before checking in the code, or we can spend time in iteration-planning meetings to go over requirements for each story in more detail.

Look for the simplest way to support an actor taking the action that will help you make your problem smaller. Is there any high-value, low-hanging fruit? Is there something that limits our options? Have we made some assumptions that may not be correct? As with your goals, use dot voting or some other technique to choose a few options to try.

I also recommend trying set-based development or a “divide-and-conquer” approach. Choose what you think are the best two paths to the goal, and have one pair work on each for a set time period. They can present their results to the team, and the team can decide if one of those options is worth pursuing further.

Set milestones to review the measurements for your SMART goals as you proceed along a path in your impact map. As soon as you see that one option isn’t going to help solve your problem, try a different one. But don’t have unrealistic expectations. It’s unlikely you’ll solve your problem in one go. If the option you try makes your problem 20 percent smaller, that’s a win. That might not even be your biggest problem anymore, and you need to go back to your goals and choose another one to work on.

Another Example
Consider the following situation. In your team’s most recent retrospective, you decided your biggest problem was that too many bugs were going out to production, despite spending a great deal of time on regression testing. To deal with this, you decide to create an impact map to identify some ways to cut down on regression testing time while still preventing defects.

A goal such as "Cut down hours spent on regression testing by half" is measurable, but what's the purpose behind it? Possibly too many bugs are getting out to production, because there’s not enough time for the exploratory testing that would find the bugs in time. Perhaps the team’s real goal is "No more than six high bugs in the next three months." Cutting regression test time isn’t necessarily going to achieve that goal. The team members then start identifying the “Whos”, “Hows,” and “Whats” that might lead them towards their goal.

Having identified a SMART goal, the team starts talking about “Who” and “How.” One "who" are the programmers. One “How” for them could be by implementing test-driven development (TDD). That will allow them to make an impact, and their deliverable would be a suite of automated unit-level regression tests.

Another "Who" could be the whole team, and the "How" for them might be "all hands do regression testing every release.” An alternative “Who” would be outside contractors or an offshore team, who’s “How” would be performing regression testing, and their “What” is test result reports.

The manager is a “Who” that could help the team find time and training to learn how to do TDD. Testers are a “Who,” and they could write the simplest possible manual regression checklists that anyone on the team could perform before each release. A system administrator labeled as a “Who” could help by setting up a continuous integration environment, providing faster feedback on regression failures.

Figure 1 shows how the resulting impact map might look. I haven’t included the “Whats,” because I feel the deliverables are so much less important than the “Hows.” Focusing on potential impacts helps teams try the most useful experiments.

Figure 1. Impact map

Having mapped out several possible impacts, the team decides that the testers will write a manual regression test checklist and a different pair of developers will volunteer to do the testing on the checklist before each release. The manager will bring in an experienced TDD coach to help the programmers start writing code for new features test-first. If they don’t get closer to their goal in six months, they may decide to try another alternative. Or they may decide to see where they are after three months and consider alternative paths.

Make It Visible, Fast, and Collaborative
Drawing an impact map together will help your team members identify useful, realistic goals, and enable them to think of more ways to achieve those goals. Remember, there are people who can help you—or get in your way—that might be outside your own team. Getting those people on board for achieving your goals together could make the difference.

The mistake many teams make—and I do it, too—is to start with a solution, such as "Let's implement the XYZ test framework." In our minds we have a goal, but we focus on a particular tool without taking the time to even know if we’re solving the right problem for our team. Impact mapping helps encourage more small experiments and set-based development.

Be creative with your solution experiments. You won’t solve all your problems or achieve all your goals, quickly. But small, quick wins and steady progress mean you’ll enjoy the journey of continually improving how you work.