Gojko Adzic is known in the Agile software development world for his work on requirements presented in his book “Specification by Example – How successful teams deliver the right software”. In this small and easy to read book, he focuses on a single tool that could be very useful for Scrum teams: impact mapping.
This approach “simply” put back in front the most important questions to ask when you start an Agile project: “Why are we doing this?” It is only when you have good answers to this question that you can start asking “with/for whom”, “how” and “what” in this particular order. Impact mapping was not invented out of nothing and Gojko Adzic gives credit and makes references to a large set of influences and associates techniques that ranges from Tom Gilb to user stories. The book structure follows the impact mapping strategy. It explains in detail why impact maps are needed and provides a step by step approach to build them. The final pages list typical organizational, facilitation and mapping mistakes. This is a book that you should not only buy for yourself, but that you can offer to your CIO and every senior manager sponsoring IT and software development projects.
Reference: “Impact Mapping: Making a big impact with software products and projects “, Gojko Adzic, Provoking Thoughts Ltd, 67 pages, IBSN 978-0-9556836-4-0
Book website: http://www.impactmapping.org/
Quotes
[about deliverables] This is the least important level of an impact map. Don’t try to make it complete from the start. Refine it iteratively as you deliver. Treat deliverables as options, don’t take it for granted that everything listed here will actually be delivered. Don’t go into a lot of details early on, there will be time for that later.
Clearly, current practices in the IT industry for managing project goals and communicating requirements totally fail to deliver business outcomes. This is not a problem only in IT. Studies of military commanders and tank platoon leaders in the US Army show that giving answers to “what” and “how” does not prepare individual teams for reacting to unforeseen problems. Yet this is exactly what most software requirements models communicate. Explaining “why” and “watch out for” is much more important in a fast-moving landscape such as software delivery.
Metrics are very sharp tools. They are great at helping us focus, but can hurt badly if we focus on the wrong things. A common problem with measurements is that they can change from being the means to control the success of a project to an end in itself.
Something in human psychology makes us come up with features as solutions. Most of my past projects started with business sponsors asking for features, a kind of shopping list. Business objectives often exist only in the back of some senior sponsor’s head, but they aren’t clearly expressed or known to anyone else. This sets up software projects for failure from the start.