VDMbee introduces it’s Agile DevOps (DORA) audit. It helps organizations to improve their performance of software development. On the occasion of the introduction of this service, a series of four blogs will be published. The first two analyze the new way of thinking about software development for you. The third turns this into a practical way of working. This is then concluded by a last blog that presents how this can be delivered to you as a service, and what this service will bring you.

Challenge

Many software development organizations (SDO) have adopted both Agile and DevOps. They aim to deliver reliable, high-quality software with a high cadence. However, reality is hard. Service delivery teams are not as productive as wanted, and integration and delivery is by far not continuous. They also fail to deliver the quality that they aim to deliver. And customers complain about the pace of innovation of their software provider.

What do you do as an SDO to overcome these problems ? Just putting pressure on your service delivery teams, to implement user stories faster and to fix bugs faster, does not help much. It may overstress your team members. And, at the moment results reach the customer, they may not match customer expectations. Working harder may even make things worse on the quality front. More-over, your measurement of how much you did, is in terms of your own estimate of what it costs the team to do things. This is not aligned with what your customers expect and observe when they get things delivered.

So, you need to do things differently. But how ?

Deliver business & customer value

First of all, you need to start measuring things where “the rubber meets the road”. This is where the outcomes of your SDO reach its ultimate stakeholders. Let’s just focus on the two most obvious stakeholders: the customers, that buy your software product, and the leadership of your SDO itself. You should start measuring what matters to them. So, you should start measuring both customer value to your customers and business value to your own business.

Consider, as an example, that you deliver a cloud-based multi-tenant benchmark management system (BMS). Multiple organizations, such as accountancy firms, banks, retail chains, etc., may have their “tenant”, in which they develop and deliver benchmarks, of financial, and sustainability performance, to their own clients.

Regarding customer value, the first value that comes to mind is price. But let’s keep that one in the court of Sales & Marketing. Customer values (metrics) that are more obvious to you are SLA matters such as Uptime, and DORA metrics like Change Failure Rate and Time to Restore Service. But there is more. You can call them “gain creators” and “pain relievers” to your customer. Your customer’s main concern may be the volume of benchmark reports delivered via BMS. And your customer will hold you accountable for how many benchmark reports BMS can deliver, per unit of time. This translates to the benchmark report request volume that BMS can handle, with fast response times. This is about a performance measure that you should measure! It is just another SLA matter. Your customer will hold you accountable also for things like data quality of benchmarks in these benchmark reports, layout quality of the reports that can be achieved, and effort (the time it takes) to develop benchmark reports. The latter three values, which are “functional”, are not only influenced by you, but also by how your customer uses BMS. It is also unlikely that your customer is already mature enough to measure these values. Instead, when it is their perception that these values are insufficient, they will respond by reporting “functionality-related” support cases. This implies that, by absence of more direct value measures, you need to measure the volume of these support cases, as well as the time needed to resolve them.

Regarding business value to your own business, you can think about Revenue. This may be about the number of customer tenants in BMS. You cannot be hold responsible for that one. But you can be hold accountable for costs allocated to the development and deployment of BMS. The first is about labor cost (hours spent on the BMS project). The cost of deploying BMS in the cloud is influenced by Service request response time, as should already be measured for the customer. Because, the shorter these response times, the less likely it is that the deployment on the cloud needs to be scaled-out.

The next question is: how can you manage the software development and delivery process, based on these values (their measurements), in a way that enables you to continuously improve the delivery of these values? Because if you can achieve that, you will meet the challenge as described above!

Agile value delivery measurement & improvement

Ensuring that the right value is delivered, requires that it is measured, and compared with value objectives. Objectives should be achievable, but should also be challenging, in order to stimulate improvement of value delivery. Value delivery performance should be assessed periodically, whereby value as delivered should be compared with value objectives as set. Value objectives for next milestones are updated during these regular assessments as well. To continuously raise the bar for value delivery.

When the value that is delivered is deficient, it should be clear where the cause of deficiency is. It should be clear who in the organization, should do what, to improve value or underlying factors of value that influence the value as delivered.

This requires that value, as delivered, is cascaded down to these underlying factors of value. Per each factor of value it should be clear which team or role in the organization is responsible for its delivery. These teams and roles should also set their objectives for subsequent milestones. In a way that enables “downstream” teams and roles to deliver their values, conform their objectives.

All teams and roles concerned should, periodically, propose improvement actions to achieve objectives. They should also commit themselves to these actions.

And this should not occur once a year, but on a quarterly basis. Or even more frequent. In the ideal case it should occur every sprint, or after every interval with a duration of a predefined number of sprints.

In order words, this system of value delivery management should be aligned with the agility of the software development and delivery process itself. Hence we denote it by “agile value delivery management”.

This practice has been formally defined as “OKR”. OKR stands for “Objectives and Key Results”. It was first practiced by Intel. It was introduced in Google, by John Doerr, who wrote a seminal book on OKRs. Many technology companies have adopted it since.

OKR

In OKR, objectives are as discussed above. Key Results are the outcomes (we say “values”) that can be measured and evaluated against the objectives.

In fact they are defined as performance increments for these values.

And these outcomes, are cascaded down to lower level outcomes, for which the various teams or roles in the organization are responsible.

Key results are set at all levels. They are evaluated against objectives at all levels.

And this happens frequently. It is an agile process.

At the cadence of this agile process, all teams and roles involved also propose their improvement actions, to which they commit themselves.

Short feedback cycle

This system of agile value delivery management can only be effective when feedback cycles are short. This means that, when a team or role improves the way of working, the effect can be measured via the next milestone assessment.

It also means that, when the customer faces a deployment failure or deficiency of value as delivered, that the event that caused this, occurred during the last assessment interval, but not longer ago.

This also facilitates that software problems can be traced back immediately, because it will be transparent to anyone involved, what went wrong, where and who was responsible for that.

The next blog will argue how “flow”, in software development, enables this system of agile value delivery management. It will also argue how short feedback cycles do not only enable effective value delivery assessment, but how they also increase the value itself that is delivered.

Do you want to know more?

VDMbee introduces it’s Agile DevOps acceleration service. It helps organizations to improve their performance of software development. When you are keen to know more, please navigate to our Agile DevOps acceleration service page. On this page you can also request information.