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