Break the software development black box

If you asked an airline executive what his biggest expense was just a few decades ago, he would have easily answered, “jet fuel.” You’d be hard-pressed to find an executive in any industry these days who wouldn’t answer with “Software”. But here’s the difference: With jet fuel, this executive would have told you he could fly x number of seats miles per gallon/liter of fuel (or pounds of fuel, if we’re getting technical). With the development of software, the expense becomes more material – and much more variable – but the return on this investment is rarely clear. Over the past decade or more, software development has easily taken its place as the fastest growing (and often largest) expense item in virtually every industry. All companies add software experiences to or around their products, and they need the people and tools to continually create, support, and optimize those experiences. And that costs money, a lot of money.

The problem is that the language, metrics, and world in which software development exists doesn’t translate into operational or financial terms that business leaders can easily understand.

“We invested X million dollars in software development last year,” a CFO might say. “And what do we have to show for it?”

Meanwhile, a tech leader might respond, “We do X deployments a day!” or, “We’ve written X thousand lines of code!”

They might as well speak different languages ​​because, in practice, they are.

And the problem is, you can’t manage what you can’t measure. To continue our airline theme, software development continues to be a “black box” – that source of information hidden in plain sight – that finance executives can’t seem to peer into.

Why the black box?

Technology leaders are unlikely to be deliberately elusive to business leaders – more likely they are simply not aligned on what they need to do, fundamentally, to speak the same language.

The question is really, “Are these investments we make translating into desired business outcomes?” But the question tech leaders feel compelled to answer is, “What do your people do all day?”

These are questions that Agile and DevOps do not answer – by translating Agile or DevOps metrics (also called DORA Metrics) into real, actionable metrics that business leaders need to understand. While these metrics are extremely useful for teams, using them to drive the business is a mistake.

Misaligned in their goals and using different language, business and technology leaders are talking to each other as software development costs continue to rise.

But the cost of software development is too high for business leaders to continue to tolerate this “black box” of ever-increasing costs. It is the fiduciary responsibility of finance executives to understand the value of software investments and how they affect business results, or else their jobs could be at stake.

In case that sounds like a distant threat, it’s not: I recently saw a headline about a prominent auto executive who lost his job because he couldn’t get the necessary information about its important software and the business results they needed. development costs and which affected the competitiveness of their entire company.

That happens. And it’s up to both business leaders and technology leaders to break that black box and start speaking the same language.

The next question, of course, is “How?”

How to Bridge the Communication Gap Between Tech and Business Leaders

For too long, business leaders have been content with activity metrics provided by technology leaders. They tolerated this lack of visibility and found other “strategic” ways to justify the increased software development costs. They may have wondered how A leads to B – how increased funding for software development might lead to greater customer retention or app usage, for example – but they didn’t. had a tangible way to prove themselves, let alone to investors, if it actually happens.

In order to understand and quantify software development costs, we need to start asking more of our technology leaders: work with them to set realistic goals and key results (OKRs), and hold them accountable for related business metrics. really to the results. This means emphasizing business results and not accepting activity metrics for them.

Stable fund products, not projects

Here’s a hard pill for finance to swallow: when it comes to delivering software-based customer experiences, it’s not about optimizing costs. It’s a lot more nuanced than X dollars in equals X dollars in outputs. Project funding can help keep the numbers clean, but it doesn’t reflect the reality of the business.

Per-project funding also tends to keep project managers in a cost center mentality: it makes all resources feel fungible; as if the work and the people who perform it were interchangeable.

One of the goals of Agile is to maximize value for the customer. But when you fund by project, you often stop funding a work–declare it done– before it actually starts generating value. We have this fake end date that doesn’t reflect the real end of the value we funded to create.

Instead, finance organizations should shift to stable product funding: funding an outcome and giving teams the flexibility to stop, change, or expand their work to achieve the product’s business outcomes.

This is a shift that a major UK bank has experienced in recent years – from traditional portfolio management to lean portfolio management, including the move to stable funding projects. You can read more about how NatWest Group (formerly Royal Bank of Scotland) made this change in this webinar.

Visualize the flow of value with flow metrics

Finally, we need to stop treating the collection of technology metrics and business metrics as two separate, unrelated efforts. Agile and DevOps are great for accelerating the throughput of your software development…but vanity metrics on how fast teams deliver aren’t enough to justify the growing, hardware-based investment in software development.

Finance leaders have the opportunity to be the babelfish between technology leaders and business leaders. As mentioned above, one way to encourage clearer communication between teams is to use OKRs to naturally tie software development goals to tangible business results. The more we practice making the connections between technology and business metrics, the closer we get to finally opening that elusive black box.

A key part of this is to communicate operational metrics differently: developing a core set of metrics to track the stream of business value in software delivery and providing a mechanism that correlates investment in the stream to the value stream of each product with the business results for that value. flow.

Visualizing the stream of value in a software development process might not be as easy as looking at the stream of value in a manufacturing shop, but that doesn’t mean it’s impossible. Thanks to the large number of data and visualization tools at our disposal, it is possible to make software products and their value streams as visible as the production lines.

The Flow Frameworkcreated by Dr. Mik Kersten, addresses the critical challenge of breaking the software development black box and bridging the gap between business and technology to optimize the flow of business value to customers.

Break the black box with value stream management

The black box of software development is, at its core, a communication problem. It is up to both business leaders and technology leaders to bridge this communication gap. Business leaders must demand more from technology leaders and insist on translating business into business action. Technology leaders must practice linking their efforts to tangible business results to help justify their growing spend.

Of course, it is useful to have tools specifically designed to facilitate this visibility and communication.

Comments are closed.