Link software development to measured business value creation

A shift in thinking for software development

Achieving the goal of balanced development starts with relentless focus on improving customer satisfaction. Translating customer needs into tangible value creation for the business requires looking at all the security, privacy and compliance aspects of the total system, including the implications arising from the complexity of needing to consider both downstream and upstream effects. This type of rigorous monitoring against such hidden requirements is what gives the customer the confidence to trust.

Organizations that take the approach of only focusing on speed and throughput fail to understand and consider all the customer needs. The end product or service might nail the nonfunctional requirements, like availability and reliability, but then fail when it comes to security and privacy, leaving unwary users vulnerable. Instead, organizations must understand a customer requirement to the depth that is required to fully protect the privacy or security of data.

If organizations try to accelerate development too quickly, without understanding the implications of the up and downstream feedback loops, they fail to meet all those customer requirements. Balanced development with appropriate automation creates an understanding that technology cannot provide adequate solutions without the context that has been gained by understanding customer and stakeholder needs.

In the past, organizations worked hard to bring Dev and Ops together -- it was about responding quickly and frequently to customer needs. Today, what we're really talking about is evolving beyond the technical domain to include non-IT stakeholders like risk, security, privacy and compliance teams. This extended involvement is a natural evolution. There are still different perspectives to consider, but all are aimed at creating value for the business and customer.

Business value comes from customer satisfaction

Any discussion on business value should touch on business-level metrics that are meaningful.  The bottom line should always be customer satisfaction. Everything aims toward that goal because every organization has a customer to serve, whether the goal be profit, community service, DevOps throughput, productivity or any other organizational objectives.

The next set of decisions surrounds risk management. Risk information should be identified early, and in a timely manner, including stakeholders as sources of new and emerging risk information, especially considering DevOps artifacts and activities change rapidly. Because risk metrics are derived from a given business and technical context, decisions should be made using a balanced strategy that accounts for delivery speed against risks of not meeting customer needs.

Finally, ensuring the organization's capability to evolve will allow for the inclusion of other relevant and much-needed metrics, such as the rate of change that arises from innovation versus routine bug fixes. Innovation should improve and increase, given close contact and communication with stakeholders, while bug fixers should decrease. However, without explicit monitoring and measurement identifying the type and source of changes being made, improving responsiveness to customers may just be a pipe dream. Each context must subsequently drive meaningful metrics but, ultimately, they should all be aligned with customer satisfaction.

Seeking a balanced value stream

Measuring the value that software development teams provide to the business implies meeting the value proposition to the end customer every step of the way. To maintain quality, teams need to set up guardrails, with triggers that identify cases where teams veer too far off course.

The journey to value starts from the customer and drives backward into the balanced value stream. We end up with something that is going to be important to the business because it's important to the customer.

Standards can provide an agreed-upon consensus on the best practices going forward because they set a baseline for everyone. This is a minimum baseline that everybody should be striving to achieve, whether for a technology, security or an organization's behavioral baseline as it establishes and builds from the customer's expectations. So, it's imperative that organizations pay attention to standards because if they're not meeting them, then they're already falling behind. Organizations have to stay up to date with current practices as innovators, in order to stay ahead of competitors.

When teams try to push ahead and take shortcuts by assuming that they fully understand customer dynamics and changing needs without finding a way to consult the customer, they don't achieve the expected business value. They fail because they haven't really listened to the customer; effective performance always goes back to the art of listening to the customer. This effort always has to translate customer needs into the disciplines of engineering, encoding those features and security requirements into the products and services that the customer requires. It's a delicate balancing act because new and emerging risks constantly change the landscape, at a far greater rate of velocity than we've ever seen before, creating a never-ending set of risks against which to deploy.

About the author
Vicky Hailey is a CMC (certified management consultant) with over 30 years of experience in virtually every aspect of organizational and systems engineering, using technology to serve a diverse customer base from governments to multinational corporations, from utilities to charities. In support of systems thinking, her SE experience has evolved to incorporate social responsibility, ethical governance, sustainability, and risk management, with a specialization in the AI domain. As well as being a practicing lead auditor/assessor, she is also an accredited ISO lead auditor instructor in many ISO management systems standards and a lead assessor instructor for SPICE /ISO/IEC/15504/33000 and other maturity model frameworks.