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.
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.