More on this book
Community
Kindle Notes & Highlights
by
Gojko Adzic
Read between
May 20 - May 21, 2024
Impact mapping is a strategic planning technique. It prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.
If a product milestone or project succeeds in delivering the expected business goal, it is a success from a business perspective, even if the delivered scope ends up being different from what was originally envisaged. On the other hand, if it delivers exactly the requested scope but misses the business goal, it is a failure. This is true regardless of the fact that delivery teams can blame customers for not knowing what they want.
good goals tend to be SMART: Specific, Measurable, Action-oriented, Realistic and Timely.
Goals should not be about building products or delivering project scope. They should explain why such a thing would be useful.
Goals should present the problem to be solved, not the solution. Avoid design constra...
This highlight has been truncated due to consecutive passage length restrictions.
Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it?
How should our actors' behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding? These are the impacts that we're trying to create.
What can we do, as an organisation or a delivery team, to support the required impacts? These are the deliverables, software features and organisational activities.
An impact map clearly shows the impacts that technical deliverables are supposed to produce, from a business perspective.
The role of testing becomes to prove that deliverables support desired actor behaviours, instead of comparing software features to technical expectations. If a deliverable does not support an impact, even if it works correctly from a technical perspective, it is a failure and should be treated as a problem, enhanced or removed.
An impact map communicates scope, goals and priorities, but also assumptions on two levels. The first is that a deliverable will cause a change in behaviour of an actor, produce an impact. The second is that once the impact is achieved, the relevant actor will contribute to the overall objectives.
Once a deliverable is shipped, we can measure the actual changes in actors' behaviour and the impact on the overall objective. We can then re-evaluate our strategy and decide whether to continue working on the same part of the map or move on to something else.
Because there is a clear mapping from deliverables to goals, we can measure when the main objective is reached and stop working on it. An impact map demonstrates that no further impacts are needed to achieve our goal.
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.
information is valuable if it reduces uncertainty about decisions, and that the “value of measuring a variable is often inversely proportional to the attention it gets”.
two levels of metrics: the ones that provide understanding and control to people outside the process being measured, and the ones that are important for the people inside, affected by the process.
We can use the metrics associated with the business goal to control the delivery and make it understandable from the outside, but we can also associate metrics with actor impacts, considering things that are important and meaningful for the people inside.
Variation: seek out new ideas and try new things Survivability: try new things out at a scale where failure is survivable Selection: seek out feedback and learn from your mistakes as you go along
Impact maps can help to facilitate the application of the Palchinsky method. By focusing on business objectives and desired impacts, a map helps us think better about alternative ways of delivering, stimulating variation. While mapping impacts we break deliverables into small pieces, supporting survivability. Finally, by visualising assumptions and defining a clear path from deliverables to desired impacts and business goals, impact maps define good measurements for feedback, helping with the selection principle.
A common cause for the disconnect between business and delivery is that teams iteratively deliver items that are too small to make a difference from a business perspective. Projects become endless streams of small items going through the pipeline, with no big picture or big benefits. Business sponsors simply don't care about small deliverables, and they wait for everything to be finished.
By trading the big picture for the ability to change things quickly, many teams lead their projects very much as if they were making their way along a dark tunnel – we don't know exactly where we'll go but small steps ensure we do not fall down.
Many teams fail to engage business users because they ask them to make decisions on the priority of software features.
Business stakeholders who worry about their needs being forgotten insist that those needs get captured somehow. Instead of writing hundreds of low-level stories, impact maps allow us to capture stakeholder needs as actor behaviour impacts. We do not really need to discuss scope for anything but the most important actor impact for the moment. Once we start working on an impact, we can grow the scope. Instead of hundreds of stories, we can work with a map and a dozen stories at a time.
With a hierarchy of visible business assumptions and impacts, impact maps allow us to prioritise whole branches easily. If the market opportunities change and one of the assumptions no longer holds, we can easily identify all the in-scope items that should be killed.
when someone wants a pet feature, they often justify it by wrapping it in a user story format. Such stories often have vague, missing or circular stakeholder and business value parts. ‘As a trader I want to trade because I want to trade’ is a classic example, along with ‘As a system I want a customer report’.
With a clear focus on business goals and good metrics to tell us when we've delivered, we can respond to questions about costs and times by asking ‘How valuable is this? How much do you want to invest? And when do you want it?’. We can then add that information as key measurements to the milestone.
A good, measurable goal is required as input for impact mapping. It is often useful to schedule two sessions: the first to define the expected business goals and measurements, and the second to create a map.
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.
Once you have a list of goals and measurements, scrutinise it. Check if everything is really part of the current milestone or if you can postpone some items. There is typically one key driving objective in a shopping list – get business people to agree on it.
Work with the group to define your learning budget: the maximum cost or length of tasks aimed at learning.
During delivery, remember that the connections in an impact maps are assumptions, which can be proven wrong.
you have to facilitate a discussion about alternatives, even if most of them will never be implemented.
