The February Revolution

22 goals not features copy I was incredibly fortunate to pull off coordinating a meeting between a group of very passionate people in the emerging space of focusing software delivery on business outcomes in London this week. The room was full of people who have been spreading similar messages through conferences and books over the last few years, along with client-side early adopters of techniques such as impact mapping, feature injection, real options, hothousing, user story mapping and similar. The task we gave ourselves was to compare all those ideas and try to extract the essence into a strong message that would help teams take the next step, and say something like “it doesn’t matter which technique you use, but follow these principles and we believe you will be rolling out much more successful software”.

My brain is still buzzing with all the great stuff I’ve heard and expect many more blog posts in the following weeks. For now, here is a quick summary of the conclusions:

Great results happen when:

  • People know why they are doing their work
  • Organisations focus on delivering outcomes and impacts rather than features
  • Teams decide what to do next based on immediate and direct feedback from the use of their work
  • Everyone cares

In no particular order, I’d like to thank very much Mary Poppendieck, Gabrielle Benefield, Tom Poppendieck, Gordon Weir, Henrik Kniberg, Jeff Patton, Ingrid Domingues, Karl Scotland, Russ Miles, Christian Hassa, Dulce Goncalves, Aaron Sanders, Shadi Almviken, Chris Matts, Olaf Lewitz and Matthias Edinger for helping define such a crisp message.

To make sure this isn’t too meta or abstract, here is my view of what those things mean:

People know why they are doing their work

A huge problem for many organisations out there is that the big picture is often not communicated to people in the front line. Different stakeholders have different objectives and those are rarely communicated, coordinated or prioritised. Software requirements and scoping models communicate what needs to be done without providing the context, which makes it incredibly difficult for people working on delivery day-to-day to make good decisions on what should or shouldn’t be in scope. It makes it also impossible to decide when the outcomes have been achieved and if they’ve been achieved at all. This creates a disconnect between delivery that measures success in rolling out user stories or satisfying requirements, and customers that measure success by business outcomes.

In addition to communicating scope, organisations should focus on communicating clearly the business reasons behind scope and deliverables (hint: this isn’t the “So that…” part of the user story, but much higher and holistic goals of the organisation). We believe that this will allow people to make much better day to day decisions and improve customer collaboration. Also, by focusing on communicating why something is needed, we create alignment between different business stakeholders and help everyone see the big picture.

Organisations focus on delivering outcomes and impacts rather than features

The measure of success, for many teams out there, is rolling out software features to production. This is when they declare victory. Teams measure and manage things like time, velocity, story points, effort. Those things are inputs and outputs, but not really relevant from a customer or business perspective unless they are too expensive. Consider a car drive. We can measure petrol (input, user stories, estimates), miles per hour (output, velocity) or miles travelled (output, user stories delivered). Those things are good to know that the machine is running OK, but they don’t tell us anything about being close to the actual objective. If we spend too much petrol or drive too slow, we know that something is wrong. Similarly, velocity and story points can tell us that. But the fact that I’ve spent half of my petrol tank and crossed 200 miles doesn’t necessarily mean that I’m any closer to my destination. I could be in Germany instead of France because I drove in the wrong direction. This is where a car GPS comes in, and shows us distance to destination.

We believe that by focusing more on measuring and managing impacts on users and business outcomes, the equivalent of distance to destination, instead of focusing mostly on inputs and outputs of the process, teams can significantly improve delivery, reduce waste, and ensure that the expected business outcomes were achieved. This also provides a framework for delivering outcomes faster, cheaper and differently than originally envisioned, which allows organisations to fully benefit from learning through iterative delivery.

Teams decide what to do next based on immediate and direct feedback from the use of their work

Many smart people have already said that organisations should incorporate learning from delivery into their plans to get the most out of an iterative delivery process. The problem we commonly see is that the feedback loop either does not reach directly to the end users, or that it is too slow or indirect. By ensuring that the feedback loop includes actual use of the deliverables, and finding ways to make it direct and immediate, organisations can leverage iterative delivery much better. This should guide the decision what to do next, driven by outcomes and impacts instead of a shopping list of features. Given a good steer in the direction of expected impacts and outcomes, the team should be able to decide itself how to solve the next problem, and incorporate the learning. Organisations that push feature requests to teams end up getting people who aren’t technical experts to specify solutions, create a bottleneck for communication through product owners who work on a level of information that is too low and fail to get the most out of their delivery potential.

Everyone cares

Several people pointed out that the big difference between opensource projects and the rest of IT is that in opensource everyone cares deeply about the products. Given a big picture view and a good set of expectations from a business perspective, if the front-line delivery people care about the result of their work, the outcomes and impacts caused by that, then they will be able to make good decisions.

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 I expect other participants to upload their notes and pictures soon, so that would be a good page to periodically check if this is interesting.

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

13 thoughts on “The February Revolution

  1. @Srinivas

    Good software is generally not easy to create. If it were, everyone would be doing it. Our message was intended to convey what we believe organisations should be doing, not what’s easy to do.

  2. Interesting concluding 4 attributes Gojko and I really subscribe to the correlation between caring and good outcome

    I guess “cares” could work on a couple of levels:
    1. cares because they have a vested interest in the outcome being successful (e.g. direct benefit / profit)

    but more often than not:
    2. cares (passionately) about what they do, the quality of their work, and innately wants to collaborate with others to achieve a good outcome.

  3. Pingback: Crisp's Blog » How to build the Right Thing

  4. Gojko,
    This definitely reflects what I think we should go for.
    Alas there is the ‘real world’ (pun intended)to take into account for now and a long way to go to get there. We had Anders Ivarsson over last Monday and when I hear how they are able to work at Spotify, I am tempted to pack my bags and go working over there. Cegeka is a great company for agile working, but our we operate in a completely different constellation. Their big advantage is that they all work for one goal/product and do not have to take into account several customers with their fixed price contracts. Agile software development can only work well in an Agile world and convincing customers to let go of command and control and really work with us is very hard; The more challenge there is for us to convince them.

    @Srinivas if you know why you are making software and you get immediate and meaningful feedback, caring of course is much easier

  5. About the “Everyone cares” part, i think that is pretty much a natural result of the first three. The “why”-perspective of what we do, and the direct feedback form the end users, is what gives us a Purpose (self determination model, Drive). And, in essence, that is what happens when we fully use a value stream- and flow oriented perspective.

    So, start with the first three, and the rest will follow.

    /Johannes

  6. @Srinivas : If you show that you trust people and truly share your vision with them, and explain why and how every move of their fingertips are the way of getting there – they might be inspired by your vision and do care.

    Simply because you cared enough to inspire them!

    @gojko Thanks for this post. We are talking about it at Valtech Sweden. Looking forward to read more.

  7. The everyone cares part *is* very important. There is a meme running around that says “Culture eats process for lunch.” Build a good environment and fill it with folks interested in the subject area and you will be closing in on your goal. People are built for cooperation.

  8. Pingback: Great results | Agil HR

  9. Pingback: Build the Right Thing: The Holy Grail | Lean Design

  10. Great article. Thanks for providing the same.

    IMHO, team or people’s working in team attitude is also very important towards work or organisation. But on second thought, it may get covered under “Everyone Cares”.

  11. Pingback: The importance of “why” – the big picture | Dave Browett-Agile Proj Mgt

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>