Why is determining business value so complex?

“Have we been successful in delivering business value?” While this question is becoming increasingly important for many businesses focused on delivering customer value — particularly those adopting an agile methodology  it’s not as straightforward as you might think.

Analysing the success of a project in terms of the value it created is obviously good sense (although there is a school of corporate thought that argues we learn as much from our failure). But how exactly do you measure business value? And who’s doing the measuring? What tools do you use? A project may have delivered excellent customer value, but to which customers? And how can you single out the teams or group members who were instrumental in driving that value?

For start-ups and small businesses, these questions are usually straightforward — after all, there are only so many cooks in the kitchen. But larger companies using agile often struggle to articulate value in any meaningful way1.

Agile was developed to increase efficiency by optimising individual features and achieving small, cumulative gains. And it’s very good at what it does. But when you have ten teams releasing at different cadences on different platforms, analysing the root cause of success becomes extremely challenging.


The problem with ‘small picture’ thinking

There are several reasons for this. The first has to do with the nature of agile. The net effect of a project or product can only be seen as part of the whole outcome, but individual team members (usually responsible for one tiny cog in the well-oiled agile machine) often don’t enjoy that aggregated perspective.

Imagine four blindfolded people asked to describe an elephant  each can only feel a small part of the animal, and this affects their interpretation of the whole. For large-scale projects, the problem gets even trickier: some team members might not even know that it’s an elephant they’re building.

Traditionally, product owners have been the only ones to enjoy an overarching, aggregate view of a project, but that may no longer be sufficient. Complex projects require more than in-depth product knowledge; they require tech fluency, high-level business awareness, an eye on marketing and sales, and an understanding of broader business goals.

Those responsible for project outcomes need to understand the relationship between business tech and business outcomes, and how those business outcomes perform in relation to other, equally worthy, outcomes. That’s a level of oversight the average Product Manager simply does not have.


You’re only as good as your measurements

Another problem is lead and lag. There’s often a significant delay between work being completed and the analysis of that work’s value. Metrics like time on page, scroll-depth, conversion rates and revenue are all valuable, but they suffer from time lag. Team members may never see the fruits of the labour (or even understand why those fruits are valuable), and businesses are always stuck with rather crude metrics.

You might be able to identify that time on page increased, but how can you be sure how much of that effect was down to UX improvements, the quality of the content, or that big marketing push last quarter? Good data can help answer some of these questions, but it doesn’t solve the over-arching problem: businesses are lacking real-time tools that allow them to analyse success of one team’s release over another’s.  

Customer segmentation and awareness is the third piece of the puzzle. Large-scale digital transformation involves many moving parts. But take a second to ask those various parts whom they’re building this product for. You’ll get a variety of answers, and while all of them may be correct, they may turn out not to be in alignment.

Agile was developed as a customer-centric methodology, starting with software development in the 1960s, before extending across the organisation in later years2. But one of its weaknesses, if left unchecked, is a tendency to think ‘small picture’. Teams become siloed and responsible for individual products, without thinking how the combination of those products will affect the end user, or even who that user might be. This is one of the big differences between simply ‘doing agile’ and ‘being agile’3.


The future of agile

So where does all this leave us? Essentially, we’re saying it’s time to mature the conversation around agile methodologies4 and customer value. Instead of looking at success as something one person measures in the rear-view mirror, we need to consider cross-functional project ownership, alignment around customer targeting, fewer lag success metrics and greater strategic visibility at the outset.

We also need to take risks. Innovation without risk is impossible, and by experimenting with different development strategies – both at the project and product level – we can more quickly isolate what works and what doesn’t. Even failed experiments provide useful data for iteration and improvement5.

‘Strategic planning’ is a good analogy to this process, but it’s not quite right: strategic planning is about setting a future foundation, often at a company level. It’s a school of Five Year Plans. What I’m talking here is at the doing level: fundamentally changing agile’s oversight structure to engage multiple teams. Defining value now becomes a group exercise, as does measuring success. By taking a more holistic, team-based approach to agile, we’ll be able to better analyse contribution to uplift.

Failure is generally easy to understand. It’s loud and uncomfortable and, instinctively, you can feel where it hurts. Success is often a mystery, and because it’s a pleasant and valuable mystery, we usually don’t take the time to observe it closely. If agile for enterprise is going to evolve, that needs to change.


Guest post by former Elabor8er, David Landry. David has been leading significant technology and business change projects for over 30 years.



  1. You either agree on creating business value, or you compete
  2. Reasons why large companies are becoming agile
  3. Are you doing agile, or being agile?
  4. Agile is the answer to transformation: but that won’t mean transformation will be simple
  5. Innovation: why not all failure is not created equal



  • DJ

    I don’t think this is a post about agile.

    Most companies don’t measure the value they deliver well enough. Particularly if they are publicly listed.

    It’s well known that shareholder value is the worst metric of them all (https://www.forbes.com/sites/stevedenning/2017/07/17/making-sense-of-shareholder-value-the-worlds-dumbest-idea/) and yet most company metrics ladder up to shareholder value in some way.

    Meanwhile most startups value their own valuation more than their value to the world at large.

    It’s a shame.

    This is not a problem with software delivery methodology (because let’s face it, this is what agile was designed for). This is a problem with late stage capitalism not being fit for the challenges of the 21st century.

  • David Landry

    Thanks for the feedback DJ

    The paper is about Agile in a larger context, and maybe the way it is articulated is the problem and not as clear as I had hoped in that regard. The intent is talk about large complex organisations and their use of Agile. To be clear this not a problem with Agile per se you are alluding to and I would totally agree.

    Also I agree on Shareholder Metrics make no sense, I thought I was making this distinction as well. But simple product team metrics do need to scale when multiple teams are all making changes in the overall systems landscape. Also there is lot to unpack when we talk about the system landscape – as most large organisations base their delivery on packages, which has a different interpretation on “bespoke” application delivery, which is typically associated with many Agile / Digitial / Teams. But as I said this is a complex conversation. I also agree that start-ups do not have this problem.

    But I do want you to consider that Agile (and Lean) are more that just software delivery alone in many organisations. Many of the new systems we are delivering not only delivery change for their customers and consumers they also change the admin and support roles in these organisations. Many large institutions have had people working in these roles for many many years. So our Agile teams need to extend their cross functionality to include this change as part of the delivery role (I have seen this done at a large university with great success). It requires the Agile view of Product Ownership / Product Management to be even more collaborative and transparent to deal with a greater “sum of parts” conversation. My view, again is only Lean and Agile thinking can achieve this for many many reasons.

    So I do some what align with you last comment of …..”late capitalism not being fit”….., however this problem is still with us, and will be for some time – so the point for us Agilists is to consider this problem.

    Thank you for the feed back. I do enjoy being pushed to consider what have said. It is great.


Leave a Reply

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