In the previous post I wrote about the key conclusions from the recent meeting on delivering software that makes a big impact. One of the best things about the meeting was that we did set-based design on the conclusions (big thanks to Karl Scotland for suggesting this). While the group I was in focused more on underlying principles, Karl’s group focused on how to get there, practical steps that would allow teams to get the most out of feature injection, impact mapping, user story mapping etc. The conclusions they came up with were also aimed at extracting the essence from all those techniques, and they are an interesting complement to the principles we identified.
The sweet-spot for all the techniques we discussed seems to be enabling these practices, and creating a self-reinforcing loop of better customer understanding and collaboration.
Understand your customer
At the core of delivering software that makes an impact is understanding the customers/stakeholders/users. Before someone blames me for stating the obvious, this isn’t just understanding their needs or desires. In What Customers Want, a book about “Outcome-Driven innovation”, Antony Ulwick warns against focusing too much on what customers are asking for, and instead advises understanding deeply what kind of jobs they want to perform and then offering innovative solutions for improving that work. All the techniques we discussed support a better understanding of users’ work and assumptions.
So to get the most out of all those techniques, leverage this aspect, and use them to understand customers’ assumptions, the work they are trying to perform and the impacts that you want to create as much as you can.
Be comfortable with ambiguity
A common thread for the whole day, as well as one of the key principles that made the final list, was to focus software delivery more on impacts and outcomes than on software features. That means that the actual software that will be delivered is not going to be precisely defined ever - we will keep trying things out until the impacts are there, and we’ll stop when they are achieved. Also, as we’re planning to learn through delivery, we can’t be certain what impacts on users’ work we’ll need to get to the outcome. With such a level of uncertainty and ambiguity about scope, there is not much point in fixing the plans or spending time planning too much. At the same time, there needs to be a good level of transparency, visibility and understanding of the delivery work and plans for everyone to coordinate (and for the clients not to panic). A common thread in all the techniques we discussed is providing a dynamic big-picture view, to prevent a stream-of-consciousness of user stories that don’t achieve anything big and make business people run for the hills.
So to get the most out of all those techniques, leverage this aspect, and make the organisation comfortable with not committing on software features, instead of focusing on making impacts. Provide a clear big picture view connecting all deliverables to business outcomes, show how they help or hinder that, and use those things to monitor and report progress.
Co-create
Another common thread, linking the techniques we discussed with Design Thinking was facilitating a close collaboration between customers/users/stakeholders and delivery teams to create solutions together. Someone (sorry, forgot who) gave a fantastic example of their organisation where they paired up a technical architect and a product person through the entire hierarchy to make decisions together.
So, to get the most out of all those techniques, engage cross-functional groups, involve customers and delivery experts, and use their shared wisdom of crowds to come up with a good delivery plan.
Learn fast
The fourth common factor for many of the techniques we discussed was that they facilitate organisational learning from delivery, establishing a clear and deliberate feedback loop from the outcomes and impacts of deliverables. In “Impact Mapping”, I wrote about this as a third weel that spins business milestone iterations.
So, to get the most out of all those techniques, focus on learning fast. This is closely related to the third principle we extracted, Teams should decide what to do next based on immediate and direct feedback from the use of their work. The more direct and immediate the feedback, the faster we can learn.
Make an impact
Organisations should focus on delivering outcomes and impacts rather than features was another key principle we set out, and by understanding customer needs, engaging them to help design solutions and learning about what worked, we can focus on making big impacts with our work, not just shipping a stream of consciousness of user stories. Many the techniques we discussed facilitate this. They help us define clear business objectives and create a roadmap that drives towards those business goals.
So to get the most out of all those techniques, don’t use them just to map out features - instead show impacts and outcomes and use those things to guide delivery.
Make it visible
By making assumptions, objectives, impacts and scope visible, those tools allow delivery teams and business users/customers to get a better shared understanding and alignment. This includes the impacts we plan to produce, impacts produced already, roadmaps, plans to learn and learnings so far. Visualisation is a common thread in many techniques we discussed, and it seems to also be a key enabling factor for a shared big picture view.
The visual aspect, as David Sibbett suggested in Visual Meetings, seems to add a lot of IQ to everyone in the room.
So to get the most out of all these tools and ideas, make sure the conclusions are visible.
Where next?
For more on this, see what Henrik Kniberg and Karl Scotland thought about it.
