Outcome Centricity: The next frontier for agile organizations (Part IV)

Outcome Centricity: The next frontier for agile organizations (Part IV)

Note: This is Part IV of the series, revolving around the outcome centricity multiple. You'll find the first part of the series here, the second part here and the third part here.

In this post I'll introduce the notion of the outcome centricity multiple and how you can use it to sharpen the outcome centricity of your (agile) organization.

Before we begin, however, let's take a step back. You're probably familiar with the following catchphrase: "Twice the work in half the time." It's one of the core selling propositions of Scrum and agile ways of working in general, popularized by Jeff Sutherland.

Now that phrase isn't just a marketing slogan, there's actually a formula behind it. The formula has two parts. On the one hand, Scrum is about (1) process efficiency, i.e. how much time you spend on delivering value vs. total time available. According to Sutherland, this number is around 5% for most teams. The second part of the equation is about (2) the relation of relevant output (useful stories for customers) over total output. According to Sutherland, this number is around 25% for most teams.

This gives you an organizational delivery capacity, as Sutherland calls it, of 1.25% for most teams. Accordingly, you get "twice the work in half the time" by doubling (1) from 5% to 10% and (2) from 25% to 50%. That is, increasing your organizational delivery capacity by a factor of four (from 1.25% to 5%).

You might be shocked to see these numbers. But what I personally find much more puzzling is how few people seem to be aware of the actual "math" behind Scrum.

Here's why: The precise numbers aren't that important, if you ask me. The problem lies elsewhere: A lot of agile organizations tend to focus too much on the first part of the equation ("Scrum helps us reduce our time to market"), forgetting about the second part ("Scrum helps us to focus on the customer").

No alt text provided for this image

To make matters worse, I believe the "formula" behind Scrum has one shortcoming: It doesn't account for customer and company outcomes, at least not explicitly.

It's likely not a coincidence that Sutherland calls it "organizational delivery capacity." The focus is on delivery, on delivering output - rather than on realizing outcomes. As I've articulated in my previous posts, an outcome-centric organization goes beyond delivering (useful) stuff. It creates meaningful outcomes for both customers and the company. This is what I try to capture by adding (3) and (4) to the equation, which together forms what I call the outcome centricity multiple.

Let's get into a bit more detail:

Firstly, for most of the organizations I've seen, there's a gap between delivering something of use to customers and actually delivering outcomes for customers. Reviews often don't do the trick either. We can't be satisfied with PO's or customers giving us feedback. We need to see what's happening, we need to measure if we're really making a difference, we need to do A/B testing. Prioritization rigor based on hypothesized customer value is not enough - validation rigor is just as important, if not more so. That's what I call (3) "outcome conversion." Outcome conversion measures to what extent your output is actually producing meaningful outcomes for customers.

Secondly, and this is probably a bit more intuitive, the original formula doesn't mention anything in relation to company outcomes. The "so what" for the company is in fact entirely missing. That's why I like to add the (4) "shared outcome factor," which is essentially asking: What's the degree of shared outcomes between customer or company? Put differently, how much value do you capture as a company from creating outcomes that matter to customers?

Let me give you an example of how the outcome centricity multiple can help organizations reach the next maturity level on their agile transformation journey. The management team of a large organization was dissatisfied with their current state of the transformation. They had started setting up autonomous, empowered teams, driving agile ways of working and a corresponding mindset. But they weren't gaining any traction in the market.

Not surprisingly, they were mainly focusing on (1), that is reducing the time to market and increasing delivery productivity. We then sat down, amongst other things, together with the teams and started reviewing their IT spent and the features they were working on. After the review, they shifted more than 20% of their strategic backlog toward epics with higher customer relevance, thereby addressing part (2) of the equation. We then helped the teams to clarify expected customer and company outcomes and setup measurement and/or experimentation processes to assess the impact of their delivery (3, 4). Some of the teams even started to present a pragmatic, self-reported overall outcome centric multiple to help inform strategic discussions with their business owners. They're now striving for twice the outcome in half the time...

As always, I'd love to hear your thoughts and feedback. And thanks Sophie for your support with this article!


To view or add a comment, sign in

More articles by Konstantin Schaller

Insights from the community

Others also viewed

Explore topics