4 of 4 people found the following review helpful
on 19 November 2012
This intentionally short book serves as a great introduction to the tool of Impact Mapping and also the principles and ideas behind it. I read the e-book version and have to say it was presented beautifully. The presentation, coupled with the brevity of the book should hopefully help to disseminate the ideas within.
Impact Mapping is a tool that is intended to help organisations to utilise 'Agile' principles throughout software development organisations rather than localising these changes within Tech Departments. It is intended to help clarify thinking in such a way as to allow organisations to derive project scope from their goals.
I've yet to try the technique of Impact Mapping but I have been persuaded by the argument for deriving product design and features from the desired effects and impacts that a software development organisation wants to have, rather than (as I am more used to seeing) from a set of desired features or features derived from perceived user needs.
The change in thinking required to use Impact Mapping, or any other tool with similar intentions, must in my opinion require many decision-makers to reach the conclusion to work in this way. As a lone voice in a crowd, seeking change, I suspect I require my boss and my boss' boss to consider these ideas.
Which leaves me with the troubling question, how do I encourage others to read it?
2 of 2 people found the following review helpful
on 2 November 2012
I have done quite a lot of work trying to get requirements out of business peoples heads in a form that can be used for software development. I have used some of the work of Tom Gilb, I have used Mind Maps amongst many other techniques.
So first off, I am very impressed with the way Gojko has synthesised a number of techniques to produce something which quickly extracts the key information from stakeholders, in a workshop environment, with more precision and yet without getting into implementation details. You don't usually get much time to do this sort of thing, so focus an speed are essential.
I have not yet tried this technique myself (but I will!), but there is an interesting vimeo which includes a section by a facilitator from a company using the technique: [...]
So another key point is the amount of background material already available on [...]
The book itself: it is nice and short, with a light writing style, so quick to read. It covers what Impact Maps are, their role and how to create them. I particularly liked the emphasis on pragmatically extracting measurements, plus warning signs for various types of problems such getting the right people, right number of people, facilitating tips, and specific mapping gotchas.
This book is well worth the price and the short time you will require to assess the relevance to you - mastering will take longer.
Why not 5-stars? I would have liked a section which took a look at another example in more detail - there is a running example through the text which is good, but an example which was almost a "play through" of a session would have been perfect.
15 of 17 people found the following review helpful
on 18 November 2012
First, a confession of self interest. Gojko is a new professional friend, who I have met at several IT Conferences. He cites and credits me, and my ideas, in his book. All of his ideas are highly resonate with my own. So, what is not to like?
On the other hand, I have a reputation, I hope, of being highly critical of most all the new IT development trends. Partly for the sport, partly because software as a trade is still so embarassingly primitive, and failure prone (a subject Gojko leads in with). So, if there is something wrong with the book, something that would waste the readers time - I am honor-bound to say so!
I have a method for reviewing books. If the point made in a sentence or paragraph is IMHO a good one, I write a `+' in the margin. If it is debatable, a `?' and you can guess what symbols I use for brash claims and bad logic. If it is generally bad for long stretches, I don't mark anything, put it aside and, politely, don't review it.
Hopefully the intelligent public won't be fooled either, by useless books. But the IT development community is famous for liking and adopting very `simple' development ideas, that don't work. Or, worse, the methods work a little better than even worse, previous methods. Our failure rate is still horrendous - a shame to the profession. I read this book in 3.5 hours straight, interspersed with other things (OK, family TV).
So how does this book rate? Every page has about 4 to 8 `+'s. There are no `-`s at all. There are a very few places where a `?' means it might be clearer for me. So that means I think Gojko has hundreds of well-formulated and useful insights (`+') that are worth sharing. Pretty good, since some books in our profession have none (IMHO).
But the overall picture is even more important than a stream of deep and useful insights.
1. He totally understands that IT and software development must primarily be about delivering real value for money to stakeholders (who he calls `actors').
2. He understands that software alone is not the solution to all problems and objectives, even in a software-dominated system or application. He understands that we have to include a notion, that others call `systems engineering': meaning `considering the totality of smartest ways to solve the problem, of delivering value for money to stakeholders'.
3. He gives us a simple co-operating set of potentially useful tools (`Impact Mapping') for helping us keep focused on the real stakeholder objectives - in spite of a complex and rapidly changing world.
He is very open to any ideas that might help us further the `value for money for stakeholders' objective, and draws on a rich, but reputable, variety of credited sources. He is enthusiastic about his toolset, yet clear about the fact that it is early days in his own personal use of the entire method, and that we need to get experience with it, and perhaps evolve it - as he already has done compared to his previous book. He does not yet offer detailed case studies, let alone scientific studies of the method. But he hopes the community will help collect this data, and specifically refers to a website to start a community of practice. If history is any guide, the case studies will arrive, and data will be collected. And `Impact Mapping' will hopefully turn out to be a useful wave of improvement.
I know, from my own experience, the power of much of what he recommends, for example the power of taking the step of quantifying the top level project drivers; to clarify the stakeholder values. This step is like day from the night of the pervasive management BS driving most all software projects.
He tries to describe pitfalls, so we can avoid them. I like such a balanced picture, and a realistic picture.
One central idea, if not THE central idea, is that there is a causal chain from the central `business' objectives of the development project, to the stakeholders, their values, and finally to the means (design) to deliver prioritized satisfaction of those values. I am totally in sympathy with that idea, and it has been totally missing from the current `agile' culture, as I have repeatedly pointed out.
IT systems are too important to society to be put in the hands of `coders' who cannot raise their sights to the interests and values of victims of their craft.
Gojko gives us a practical set of tools to work this value chain, and maintain its integrity during change.
Are their things I would improve upon? Of course; and so will Gojko, and hopefully maybe you, reading this. But we all are subject to the cultural maturity of our clients and students. We cannot impose `ideas of sophistication' on the many who are not yet motivated, experienced and ready for such `improvements'. Culture change takes decades, at least, and we have to be patient.
I, for one, would be delighted if Gojko helps us get more buy-in, for real, of the central practice of `recognizing that the central mission for IT developers is to consistently, early, frequently, and cumulatively deliver central, critical, high-level improvements to the stakeholders'.
Imagine if we `nerds' one day became famous for our ability to deliver amazing value quickly?
18 November 2012
1 of 1 people found the following review helpful
on 17 December 2012
The book is intentionally concise and precise, since its purpose is to be a reference, both visual and textual. It describes a methodology on how to describe the impact that new projects/applications will have on the business. This methodology involves continuous and peer-oriented exchanges between business experts and senior consultants/IT experts. Its result is a visual map that helps understanding the goals of a projects and how the involved team can achieve them.
I still have to test by myself, but it seems that the methodology can be introduced quickly, given that the team is prone to it (and probably that the team is made by professionals already working together). Obviously mastering it is no way an easy task, and experience is required in order to be effective in impact mapping.
Overall a good reference on a technique that may change the way the teammates work together when defining a new project goals and the way to reach them.
1 of 1 people found the following review helpful
on 21 November 2012
Hi - I realised yesterday that I had a problem describing the objectives of a software project and articulating it to stakeholders. This morning I read this book, this afternoon I implemented my first impact map, and it feels much better than the reams of documentation I had been busy not quite getting round to updating, and the various powerpoint decks I never quite got to the end of. So on the technique itself, very useful.
On the book itself - it is a simple idea - well described, without un-necessary padding. A key thing here is the book is short, it doesn't waffle like many other similar books. I literally was able to read and being implementing in a day.
on 30 January 2014
In many companies, the gap between business people and development team is pretty huge.
- Dev teams are working using a water-scrum-fall methodology. This means that only the development teams are agile while the business is still working old school style.
- Dev teams and business should communicate really more.
- Communication is often a document-based communication. Business and dev teams are “sharing” information only via specifications documents
- Dev teams are not aware of the real business goal behind a not-that-well-written user story; they do not know what kind of business value (impact) their development would bring.
- Dev teams and business are even not speaking the same language!
This book will give you the right tool to solve all this.
Impact mapping will get business and technical people together. They will share goals. They will share and agree on what are the different options that would reach the goals. Business and technical people will build the map together, having the same objectives in mind, sharing the same vocabulary. Even user stories will be tied to the impact map, using the same actors, impacts and deliverables. This will obviously bring agility into business team as switching to one branch to another if the first choice doesn’t match the measured goal, requires a short feedback loop.
Thank you Gojko for having gathered all those great ideas within that short, useful, practical, reference book!
on 13 November 2012
This book provides an overview of Impact Mapping, and has purposely been kept short.
Having read this, I like the problems it is trying to solve, more specifically, the problems it is highlighting as being a common factor for project failure. I like the way Impact Mapping encourages collaboration across teams to clearly identify goals and the means for reaching said goals:
"Senior business sponsors are usually not technology experts, so the solutions they propose might not be optimal (cheapest, fastest to implement, least risky or whatever makes solutions optimal in your context). When the business goals are not communicated clearly, technology experts cannot suggest a better solution if it exists"
How true this is, and how easily Impact Mapping appears to facilitate this alternative discovery.
"Assumption is the mother of all f**" goes the saying, and for me I like the fact that Impact Mapping provides a way to highlight assumptions clearly.
I look forward to seeing how the community around Impact Mapping grows and how this might be applied to my future projects.
Again, I would give this 5 stars, but I think a few more examples would have been good. That said, there is further information on the website and I'm sure as the community grows there will be further real world examples available.
Short but sweet.