London 2013 experience. Part I. Impact mapping with Gojko Adzic
Recently I’ve spent a week and a half in England, mostly London, but also went to Brighton for a day. When you spend most of your days working in the same room, without moving too much, or talking (in person) to anybody, this is a big deal. I went there to attend to two conferences, Responsive Day Out and QconLondon but also to visit my sister and friends. I learned a lot and met many people, also got time to know a lot better two people I don’t get to see very often @jaumejornet and @david_bonilla, thank you guys!
In this post, I’ll share the experience which impressed me the most, and that is Gojko Adzic and Russell Miles’s workshop “Impact Mapping - How to Make a Big Impact by building Valuable Software Products and Projects”
Impact Mapping
Agile methodologies are great for getting feedback soon in order to build the right thing. This is: developers taking a set of user stories which non-developers can give feedback on. But how are this user stories created and prioritized? This is usually a process in which people involved in the project bring their own set of assumptions. Each discipline has different sets of assumptions.
The impact mapping technique focuses on making explicit these assumptions by visually showing the WHY, WHO, HOW and WHAT of the problem we are trying to solve. The technique combines some old ideas and a bunch of pretty new ones, into a coherent process, that modifies how decisions are made in your project. So that instead of ending with a tunnel-like roadmap, you end up with a truly multiple choice roadmap with a lot of possibilities to choose from, test, learn and decide over it.
To draw an impact map you need to address this four questions:
- Why? This is the main reason of all these. Why are we doing this? It’s important and not always clear, to state the business objectives behind what we build. Do we want an affiliations feature on our e-commerce, or do we want to reach 10.000 more customers?
- Who? Who will be impacted by what we are building? Who will produce the desire effect?
- How? It answers the question: How should actors’ behavior change? This level is the most difficult to address, at least it was for me during the workshop, because as builders we tend to skip this question and think in terms of technical solutions.
- What? And finally we can think of features. What do we do?
The idea is to go up and down the different levels and hopefully come up with multiple possibilities for every level, building some kind of tree for the goal or why-level.
I’m already implementing this technique with my team in a project, reading about it and trying to engage with people who are also experimenting. I’ll talk about our results in a future post, and maybe more details about this topic. I recommend you to read the book and I live you with some links for more information: