DevOps focuses on continuous value delivery to the customer…

…now what does this – actually – mean?

If you know me, then you will know that I am not big on Americanisms and business speak. I tend to like to say how it is and be pragmatic, even if I go on a bit at times.

That being said, when I talk about DevOps, talking about the somewhat elusive concepts of “value” and “impact” is kind of inevitable.

A common question I get is around what value delivery actually is. Like with many other aspects of DevOps we can learn from manufacturing here.

Let’s start by establishing how we measure the “amount” of value delivered…

If you work in the private sector the quantity of value will likely ultimately be “money earned”.
Having typed this line out I can almost hear you yelling “but we are all about the customer”, and “but we are an ethical company” at your screen, and – no doubt – many of the people I talk to regularly would agree with you. But let’s explore this some more.

In the private sector businesses need to make money to continue operating. As a result we can break value generation up in the following categories:

  • Protecting Revenue
  • Increasing Revenue
  • Reducing Cost
  • Avoiding Cost

Looking after your customer, building brand loyalty, and best-in-industry support, will help protect your revenue and avoid the cost of increased advertising to attract new customers.

Many value generation efforts – in software development, we’d usually call them “features” – will touch more than one category. A streamlined sign up experience to your service might increase revenue, but it may also reduce costs as it increases the overall performance of the system and allows you to decommission hardware.

If you still disagree with the concept of value being the money that we make as a business, then that’s fine. You might prefer not to read the rest of the article as the following sections will not really make sense. 🙂

Value generation is more abstract in the public sector. Depending on the geography that the organisation operates in, its budgeting situation, and government policy, value might only have an indirect relationship to money. (whether that is money made or spent)

Usually governments will define policy targets of delivering a particular service to a certain number of individuals. This can be “value” and we need to make sure any system that we built can track both the availability and the delivery of the service in question to them.

Okay, but how do we know how much “value” we deliver?

Just like in manufacturing, we can see the different stages of our development process as work centres.

If you do this for the first time, the centres might not be necessarily obvious.

You might start with a structure akin to:

  • Business
  • Dev
  • Test
  • Ops

And then later discover that for the particular value chain that you are exploring it is actually:

  • Analysis
  • PM
  • Dev
  • Windows Server Ops
  • Test
  • Cloud Ops
  • SQL Server Ops
  • Support

To get a good view of the value chain, you should track a particular requirement as it travels through your organisation.

  • Who makes changes to it?
  • How long does it sit in a queue?
    • Where are these queues?
    • What tools (Outlook, TFS, etc.) are they represented in?
  • Why are there queues? Why are the receiving work centres busy?
  • How much work arrives in a “correct and accurate” fashion first time round?
    • This is another term that is borrowed from manufacturing
    • It describes the amount of products (as a percentage) that are correct the first time round and do not need any rework

Once you have explored all of these questions, you should end up with a value map that shows tool chains, work centres, queues, wait times, and “correct & accurate” percentages.

If you look closely at the example, you will see that there are roll up figures at the end that show the overall activity percentage and a rolled up C&A percentage.
These figures are used to visualise the actual work time and the queue time as well as the amount of rework required respectively.

Obviously exercises like the one explained above will always be biased towards a particular ticket, but – if done consistently – can still help you create an overall picture of the speed of the value delivery process.

If possible, the process should follow the requirement from the request stage until it arrives back at the customer. (It does not matter if this customer is internal or external to your organisation)

If done consistently, well maintained value stream maps can help you identify:

  • Bottlenecks in your organisation
    • Engineering function with a long queue
  • Unnecessary sign off processes
  • Tool chain crossovers
  • Delays due to technical, people, and process problems
  • Amount of rework required

Many of the metrics shown can be gathered by using a lifecycle management tool (like TFS for example), but there is also a lot of merit in completing this exercise in a low-tech fashion, as it helps you get to know all the work centres that an item is touching before it reaches your end customer.

Finally value stream mapping also helps to build a better picture of the delivery process and encourages you to think about your technology practice as a single system that delivers value. It makes it easier to optimise the overall process instead of focusing on micro improvements.