Using Impact Maps for planning and controlling process improvements

The typical outcome of retrospectives should be process improvements. Books like Agile Retrospectives and Gamestorming offer a wide range of ideas for conducting these meetings. Tools for enabling the team to envision improvements more methodically and strategically are seldom found.

Products should be solutions to real problems the customers are facing. Process improvements should be solutions to real problems the team is facing. Impact Maps are a method to strategically develop products or on a wider scale strategically deliver solutions to problems. So they seem a good method to try out.

Analysis of Impact Maps

Impact Maps are composed of four different layers:

• Why are we doing this?
• Who is going to help/hinder us?
• How can they help/hinder us?
• What do we need to do in order to enable/disable the "How"?

A more detailed explanation can be found at http://impactmapping.org.

Field test

In order to verify my assumptions I tried it out with my coached teams.

Setup

Two scenarios were created:

1. Impact Mapping is used for conducting the "Generate insights" phase. The resulting Impact Map is not reused in the following retrospectives.
2. Impact Mapping is used for conducting separate team improvement workshops. The resulting Impact Map is used as the backbone of future retrospectives.

Please keep in mind that the tests were done with two completely different teams. So the significance of the outcome is lacking. The tested teams were Scrum teams consisting of approxx. 7 people.

Results/Insights/Observations

Scenario 1

First of all it highly depends for what exactly you are generating insight. In general you will have two types:

• Problems
• Improvements

So similar to shopping lists in product development you are starting here with the same thing. You have a shopping list of problems or improvements. As a start work with the team to create a common goal (The why) for this Impact Map. Good retrospectives should have a goal, so this will be easy e.g. increase the percentage of delivered User Stories to 90 %.

Now let the team come up with the missing link from the problems (The how) and improvements (The what) to the goal. This means the who lane also gets populated. Don't forget that the team is also an actor. There is an easy sanity check of the problem/improvement: If the team struggles to find a connection to the goal discuss it with the team. The problem/improvement might not be important.

In the end you will have a lot of immediate improvements that the team can do. A quick blind voting will provide you with the improvement which should have the most value for the team. Why a blind voting? To avoid bias and strategic voting behaviour.

In the next retrospective you can reuse and expand the Impact and do not forget to review the improvement: Was the projected benefit achieved?

Results

It works very good for generating and selecting the most valuable improvements. Unfortunately it is quite hard to reuse and expand the Impact Map over the course of multiple sprints without severely altering the Map - which is fine. Just keep in mind that an overpopulated Impact Map is not perceivable anymore. So trim out the old stuff.

Scenario 2

Use the same approach as you would facilitate a product workshop with the help of an Impact Map (very simplified):

1. Gather "shopping lists" (problems + improvements)
2. Agree on a goal
3. Start connecting these items
4. Populate the Who-layer
5. Select the most important actors e.g. via blind voting
6. Populate their How-layer
7. Select the most important Hows
8. Populate the What-layer
9. Select your immediate What/improvement

This works quite well as the team is starting to think how they are embedded in their environment and who is going to help/hinder them. Of course it is encouraged to use techniques like stakeholder maps to facilitate this workshop. Make sure that you incorporate the results and the map into the future retrospectives. Keep the Map updated.

Conclusion

In my opinion Impact Maps work great when used for process improvements. Although I recommend to commit to using an Impact Map for controlling team development. Otherwise it is "just" another game played during the retrospective 😉. Make sure that the Impact Map is visible and present in the "War Room". Electronic Impact Maps are nice for editing and keeping a backup but they lack the visibility factor. If you want to create electronic Impact Maps I recommend MindMup.