Is your software a cost centre or a value engine?

When’s the last time you seamlessly went from the ideation phase to the production phase (i.e. the point where customers could get use and value from your solution)? Follow-on question: was it good, fast, and cost-effective, or could it have improved on some or all core business measurements of success? 

Software delivery often confuses (or rather neglects) measuring impact to the business, focusing instead on metrics like story points, sprint velocity/burndown, cycle time, bugs fixed, and features delivered. While these are important metrics to consider, I mean we all want to build the right thing right; they don’t necessarily quantify impact of what is delivered. 

I think it’s time we (as software teams) focus on more deliberately integrating and aligning business outcomes into the software development lifecycle (SDLC). One possible unifying theme for this could be time-to-value (TTV), i.e. how are we actively tracking core metrics for business value in what we deliver against the time it takes us to deliver it? 

Maturing our processes to include TTV would offer benefits back to our stakeholders and ultimately enhance stakeholder satisfaction through:

• Faster and more easily explained return on investment
• Reduced risk through demonstrable value aligned to business outcomes
• Competitive advantage by being able to respond more quickly to changes in the market

Making this actionable, we could better prioritise based on business value (through approaches like impact mapping for example), align our MVPs and milestones accordingly, and build mechanisms to measure business impact as part of the SDLC. Imagine understanding how each code commit/deployment cycle positively or negatively impacts the business case, not just technical excellence? That’s some high-fidelity data-driven decision making, right there. 

This isn’t the easiest proposition. It’s sometimes difficult (nay, seemingly impossible) to objectively measure all aspects of business value. It’s a mindset change, so this needs to effectively integrate into the culture and way of work. It pushes the tension lines of balancing speed and quality. It will probably make stakeholder negotiation trickier, especially when managing diverse expectations and views around business value and priority. 

But in my opinion, it’s worth it. With the time investment in developing a software practice that aligns business value with engineering best practices, the benefits can be substantial. And using a common theme that both business and technology can align around, such as TTV, it can lead to more agile, responsive, and value-driven software development in the long run.