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 way¹.

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 years². 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 methodologies⁴ 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 improvement⁵.

‘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.

References:

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