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.