February revolution, part 2

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.

february_revolution_practices

(click on the image to download a larger version, feel free to use it in your slides, presentations etc).

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. Also, we created a Google+ Community to hold all the photos and links and there is plenty of good stuff there already.

I'm Gojko Adzic, author of Impact Mapping and Specification by Example. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter. Join me at these conferences and workshops:

Product Owner Survival Camp

Specification by Example Workshop

Conference talks and workshops

7 thoughts on “February revolution, part 2

  1. Nice post & some great ideas to think about – thanks for sharing Gojko.

    I do have a question though – what if the job the customer is trying to perform will not solve their problem?

    Should we help persevere with that job which is destined to failure?

    Or does this come in trying to understand their assumptions, as in why are they performing that job to solve that problem?

    Duncs

  2. Regarding Duncan’s post and your statement that we need to focus on what jobs the customer is trying to do, here’s a quote I’ve had up on my wall for years:
    “If I had asked people what they wanted, they would have said faster horses” -Henry Ford.

    Our job is to help them do their job better, so we should be trying to discover what they really need.

  3. Gojko,

    I find the insights in Impact Mapping to be extraordinary. However, I’m a little confused about two terms:

    Scope – How do you define scope? Is it the same as a collection of features?

    Milestone – is a milestone the same as a goal?

    My apologies for the elementary questions, but they had been points of struggle for me.

  4. Impact Mapping will your customers to understand better. My thoughts are also same that which you mentioned on start the post as image. Make it visible for your clients.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>