Impact Mapping is a collaborative planning technique that helps organizations define good objectives or sort delivery from a business perspective not just from a technical kind of “these are the user stories that we’re going to do” perspectives and it helps everybody align with those goals, it helps organizations to track whether they are going the right direction and ultimately helps people deliver much better software.
My previous book Specification by Example was kind of a series of interviews that I’ve conducted with about 40 teams on 50 good case studies and what was really interesting for me then is that the most successful ones didn’t really start with user stories. There’s a lot of literature out there that says that a smaller case in Agile where you do one of those methods that are under the Agile umbrella, people can often say that the teams start interacting with the business through user stories, through product owners and things like that and what was really interesting for me to discover is the most successful ones didn’t do that. They kind of pushed the envelope and pushed interaction one stage earlier where the technical people and the business people got involved in really defining good business goals and then making sure that the scope that gets delivered is derived from those business goals. So I included that as a chapter in the Specification by Example book, just to make sure there’s a complete picture and deriving scope from goals was one of the key buttons that I talked about there. But I didn’t really go into a lot of details there, because the focus of Specification by Example is mostly on given a user story, what do we do with that? Impact Mapping is one of those techniques that complements that picture. It says that “here’s how we come up with the right user stories and here’s what makes this particular user story right for us now”.
I think so. Impact Mapping is based on community organization techniques that people developed in the 60’s. It is based on some good ways of adopting training through organizations to deliver business results that Robert Brinkerhoff wrote about in the 80’s and 90’s, so it’s not really software specific at all and I’ve used it also for financial planning, for our consultancy and I know that a couple of companies have used Impact Mapping to think about further process improvements and it doesn’t have to result in software and that’s one of the brilliant aspects of it, is that not all solutions are software really.
Impact Mapping is a technique that requires a cross functional group of senior business and technical people to align their expectations and visualize their assumptions together and it uses a collaboration model, first described by Gib, Weisbord and Drexler in their work on getting communities to kind of plug better, which is asking for basic questions. These questions are: Why are we doing this? Who do we need to help? Who are our customers? Who are our consumers? Who are our stake holders? How does their behavior change as the result of what we do? How does what we do need to impact them or what impacts are we creating and then, on the fourth level, we ask the question: What can we do as an organization to cause those impacts? That’s just a structured conversation that then results in a mind map that is a visualization of business assumptions, business objectives, stake holders and ultimately software scope but also quite importantly the impacts that we are trying to achieve. Anthony Ulwick wrote a great book called “What customers want” as a result of his involvement in the PC junior project at IBM and he said that one of the biggest mistakes they made was focusing on work that people do, not the change in the work that they wanted to cause and Impact Mapping makes that very explicit, it requires people to answer not just what kind of work people need to do with this, but what is the change in their work.
To put that in the perspective of user stories, for example, a user story that says: “As a marketing manager, in order to understand the results of a marketing campaign, I want a particular report”. Understanding the result of a marketing campaign is the work that this person does, but he was probably able to understand it before any software was done, he was probably able to understand it before this particular user story was done and he will be able to understand it later, so there is no real success criterion for that user story, apart from ticking the boxes on technical tests or things like that, where if we think about changing the work in order to be able to understand the results more accurately or understand the results faster or somehow differently, that then gives us a success criterion to that user story, which then allows us to compare that to other behavior changes, look at what other things could we do to cause that behavior change and a lot of other things.
5. What has been the reaction, so far, to your book and this approach you are proposing?
The reaction was incredibly positive. I think it has many more reviews on Amazon than I expected to get and a lot of people I respect quite a lot dedicated 10 minutes of their time to go to Amazon and write a very positive review, which is fantastic. I get a lot of e-mails from people that kind of tried this in their organizations and got fantastic results and so far the result was overly positive and I am really glad about that.
First of all, I don’t think I came up with that. It’s not my idea. I think I just connected the dots and those ideas were already there and a lot of what I wrote about in Impact Mapping or what I do with Impact Mapping in organizations has been around for 20 or 30 years. It’s been around in other industries or even has been in software but not applied in that kind of collaborative way. So the key difference between Impact Mapping and other techniques that already existed, even in the software world, is that Impact Mapping is collaborative, is visual and is fast so I wouldn’t like this to sound like I’ve invented it because I’ve just compiled those ideas together. The motivation for me was that, basically, I worked with a start up where we ran out of money and we prided ourselves on being the best delivery team in the world, doing continuous delivery, doing automated testing, doing all the things that people write about in technical articles and promote through technical conferences and we still ran out of money. And I had to take a long look in the mirror and tell myself that we were not that good and then I started realizing how much wasteful work we’ve done by doing the wrong thing and I started noticing that in other places as well and with my clients. That really prompted me to think that for a large part Scrum and XP and Kanban have solved the problem of getting stuff out and lots of teams that I meet now can deliver almost anything that their business people want but they spend an insane amount of time doing the wrong thing and I think the bottleneck has moved for a lot of the teams. Not for everybody, of course, there will still be people who can’t get things out but for a lot of the teams that I meet and a lot of the people I talk to, the bottleneck has really moved, the team is no longer the bottleneck.
The bottleneck to great software now is delivering what’s really important, delivering what’s good and there we fall into the problem of: we’re either going to accept some very heroic assumptions and go and deliver (that a lot of teams do and they fall into this stream of consciousness theme of delivering user stories endlessly where there’s no big thing ever delivered and there’s no big picture) or they fall into a kind of what Forrester research called WaterScrumFall, where there’s a one and a half years of business decision making and then after that, you children can go and play a Scrum, which then completely defeats the point of iterative delivery, so where the Impact Mapping connected the dots for me is that it enabled us to see the big picture, it enabled me to work with teams and provide a common big picture between business and delivery, but still not spend a year and a half doing that, instead spend one or two days doing that for six months of delivery and then being able to very dynamically react and adopt learning from delivery. The interesting thing about it is that for the teams where the bottleneck has moved, where the team can actually ship anything out, Impact Mapping will provide a really good fit for kind of getting the business integrated into iterative delivery and providing a lot more value to the business and the whole organization by doing the right thing.
So I think a big part of it is first visualizing those assumptions. For many teams out there that I’ve worked with, when I think about this retrospectively, those assumptions were never communicated or visualized. What gets communicated is software scope, in whatever way, user stories, use cases, it is just kind of “These are the things we need to do”, it’s not the underlined assumptions ”What makes these things good?” and the first step is actually to get these assumptions out in the open, because I’ve realized, working with several larger organizations, if you have 20 or 30 different business people that are stake holders for a particular project, these people have wildly different assumptions and some of them will conflict, some of them are kind of ok to test and some of them don’t make any sense when you get them out and starting delivery based on that. Again, is a very risky proposition. So at the same time we can’t spend three years analyzing all those assumptions and even if we could, nothing guarantees that the market opportunities are not going to change as we deliver, so the assumptions will no longer be correct.
So I think visualizing those things is the first important step and then the second step is trying to figure out, and this I why the Gib-Weisbord-Drexler model is so important, it provides the missing link between the overall big picture and the software scope. It gives us what behavior changes do we want to cause, because it gives us assumptions at two different levels, which then we can start testing. So we can start thinking about how do we know that changing somebody’s behavior in this particular way is going to contribute to us in a good way and then we can find good ways of testing that. We can also think about how do we know that this particular user story is going to start changing this particular behavior. It’s not such a big leap, there’s a step in between and there’s two levels of different assumptions. What I do to kind of get people to prioritize is I carry a lot of fake money with me all the time and you can buy this stuff for 5 Pounds from Amazon and things like that… I don’t know if you can see this but the Euros look pretty good, the Pounds are not that good and I carry a lot of fake money with me all the time and we use a variant of what Luke Hohmann basically calls “Prune the Product Tree” where given all these assumptions we just give people fake money to buy stuff.
So the Euros look pretty good, here’s a fake 50 Euro, the Pounds are not that good but you can buy a whole bunch of these for 5 Pounds from Amazon and what that tends to help with, is it gives people a different perspective, it switches from cost to investment. They no longer think about how long something is going to take or how much is going to cost, they think about how much time and money can we invest in this. And then you can start thinking about “Ok, this is an important thing, deciding what to do here is quite an important decision” therefore it makes sense to invest a bit of money into learning that or, you know, looking at this “Well, it’s not that important, the assumption doesn’t really matter, let’s not do it at all or let’s just do something very very simple”. It moves the mentality from thinking about cost to thinking about budgeting, which I think is quite an important switch that people should make more.
Again, this is not my idea, I’ve read this in a great book called ”How to measure anything” by Doug Hubbard. He talks about the value of information and there’s a very strong statement there where he says that one of the ways to measure the value of information is to basically make it proportional to the value of the decision that it informs. If we are trying to make a decision on what to do strategically about our flagship product, that’s quite a valuable decision and the value of that information is high therefore we can invest in measuring, understanding that piece of information. If the value we’re trying to make is what to do next week and it’s not that important, then we don’t have to invest a lot in measuring that. And what Doug Hubbard says is that basically without understanding the value of a piece of information, people tend to measure things that are easy and cheap to measure, not things that are valuable to measure and by thinking about, again, from an Impact Mapping perspective, what are our biggest assumptions and then what decisions would these assumptions inform, if these are important decisions, then it becomes natural to invest something to measure that and there’s a lot of literature about this.
Tom Gilb, for example, wrote about investing 2% into every cycle of delivery for understanding what comes out of that and that’s quite a good example of a learning budget, where you’ve decided we’ll invest 2% of our budget into learning, is this the right thing to do? And if we decide it’s not, we’ve spent 2%, we’ve not spent 98%. If we cannot learn something in 2%, then we can find easier ways or better ways of learning that.
For example I’ve worked with an organization where somebody proposed that inviting people through Facebook is a good way of approaching a problem and we said ok, what would be a cheap way of learning that? And then we said our learning budget for this is one week, we have to do something that’s less than one week in order to learn this and we came up with several ideas, the simplest one was basically to have a static button where if people click on it, we can measure the clicks and we see that people are inviting their friends, so they are likely to invite people, also we would just dump their friends e-mails into a text file, not having anything automated in the backend and would kind of learn that, yes, people are inviting friends, we could also stay overnight and send those e-mails manually to learn whether the people are responding to that and this gave us a very cheap way of learning things. So the user story itself did not deliver any particular high business value but it delivered the learning value that provided us with better marketing templates and then it informed us later to go on and deliver something really valuable. We didn’t rush our head and delivered something based on broad assumptions, we iterated through it several times by manually sending e-mails, to actually discover what works and what doesn’t work.
That’s a very interesting question. I guess there’s a lot of mental blockages, especially on the mid management level where people are tasked with delivering a particular set of requirements, so a project manager will get a project to deliver, he doesn’t really care about the business value it delivers a lot. I typically get called in by relatively senior people when the situation is not going that well. So in that particular kind of situation, people are open to change and to try new things because the current thing doesn’t work. How would we raise awareness of that in an organization that doesn’t see the problem yet? I don’t know, I guess I get called very often by people who are not that high in an organization, they are kind of working on the ground but they want to give a broader overview to their management and they can schedule an innovation day. Lots of companies now have a company kind of retrospective or innovation day or internal meetings and that would be a good time to try one of these things. We are at a conference now, conferences are a good way of raising awareness, books are a good way of raising awareness. We do, as part of Impact Mapping, try to actually help other people raise awareness, so we started this consulting program where people who want to promote this approach in their organization or with clients can get intellectual property for free, images, presentations, ideas to run workshops, that’s all available on ImpactMapping.org and that’s one way of promoting this.
I don’t know. It all depends on how you understand that and I think the word Agile, although I do still tend to use it, over the last five or six years lost all meaning It has became so vague and so broad that people now go around, they buy a cork board, they put it on the wall and hey, they’re Agile. And a lot of it is just bad implementations unfortunately and if you look at, I’ve mentioned Forrester research report, if people google for WaterScrumFall, they will find that, it’s one view of the industry. Certainly my experience of the industry has been compatible with that view where lots of organizations adopt all these practices only for development, very rarely involve the rest of the organization in it and I think Scrum product owner and misunderstanding of that and XP customer are to blame largely for that because they are understood by a lot of teams as a kind of proxy and a shield between the team and the organization around them and they promote separation rather that iteration where the first principal of Agile manifest is interactions and Agile manifest promotes collaboration and things like that.
So I think a lot of it is due to bad implementations and misunderstanding. Whether Agile has peaked or not I don’t know, I’m not really the right person to say that, I think those practices help quite a lot. XP and Scrum in my view and I’m not a certified Scrum anything and I have no intention of becoming one and my experience with XP is again… working with teams and I wasn’t there when they invented it, my understanding is that they are much more about “how” than “what”. They’re much more about helping teams find out good ways of delivering software, not actually deciding what to deliver and that’s why I said I think the bottleneck has moved. I think a lot of teams have conquered that, they have good ways of delivering stuff but now the bottleneck has moved to what’s the next thing to deliver and that’s an interesting position, so it all depends on your definition of Agile. If you look at the kind of stuff that Chris Matts is doing with Feature Injection or Dan North’s accelerated Agile or behavior-driven development, that’s a lot more about what to do next and I think these are all pieces of a bigger puzzle and you do need to deliver things well and you do need to deliver the right things in order to be successful.
That was quite an interesting meeting and I’m fantastically fortunate to have helped organize that. We got together to try and understand is there something common for all these separate techniques and then I think we nailed it down to 4 key principles. The first principle is that everybody should really understand why something is being done, not from a perspective as a marketing manager in order to do this, that’s lower level, but why, what does the organization get out of this. What are the key assumptions and things like that and when people know that they can much better align their activities, they can spot problems, they can make much better decisions and again this is nothing new really. People have been writing about this since the Napoleonic wars. At least that’s the first instance I know of that, maybe even earlier.
The second thing is that organizations should really focus much more on achieving impacts rather than delivering software and achieving impacts through changing the way people work, changing the way people interact with us, achieving some business objectives. Because at the end of the day, if we achieve that, it doesn’t really matter what software achieved it or if we have achieved it with software at all. If we deliver exactly all the user stories that the product owner wanted but we missed the business objectives, then the delivery doesn’t really matter. We might have 5 thousand acceptance tests and 7 thousand unit tests passing and the build that finished in 3 milliseconds, but we’ve missed the business objectives, so it was a waste of time and I think you do need to align both. The third principle we defined together is that we should decide what to do next based on immediate and direct feedback from the user of the work and that means that people shouldn’t plan for the next six months of work and set that in stone. What’s most important compared to (again this is not a new message, XP, Scrum, have been passing this message for a long time) but the key difference here is that the feedback that needs to inform what to do next, needs to come from the real use of the work, production use, not deploying to production, not acceptance tests, not somebody’s opinion but really the use of this thing. That then informs the decision of “Was this assumption right or wrong? Have we caused this behavior change? Do we do more to cause this behavior change? Do we stop? Do we do another behavior change to cause some business objective or do we stop?”.
And the fourth principle is everybody cares and I think that this means that everybody should really care about achieving those business objectives, aligning the work with that and these things are kind of tied in a self-reinforcing loop. If you communicate why, if you focus on objectives then people will care, if people care then we’ll get more business objectives done and things like that. So those are the 4 key principles that we identified common for almost all these practices and I think in retrospect, you don’t have to use Impact Mapping, you don’t have to use Feature Injection, you don’t have to use any of the other things. I think if you have a process that keeps to those four principles, you will get good stuff out of the door.
Manuel: Thank you very much for your time!
Thank you!