Visualising Continuous Improvement

By Software Development Team Lead, Jon Vines.

The promise of adopting DevOps practices, including tooling and deployment automation suggests that we will be able to deliver value more often. But where do we measure from, what measurements assure us we’re doing the right thing, and is that shiny automated deployment pipeline really the answer to unlocking the value potential we can deliver?

To understand how our improvement initiatives affect our delivery of value, we need to take a step back. We need to look at our value stream from idea to production and think about the system as a whole.

A value stream is the sequences of activities an organisation undertakes to deliver on a customer request

A value stream is all of the activities that are required to take a customer request and put the result into their hands. Within our teams, we can utilise a value stream mapping exercise to determine all the steps we go through to take a business request and deliver that request into production.

Value stream mapping as a concept is rooted in the lean movement of the 1990s, first mentioned in The Machine That Changed the World. It was further defined and codified in Rothers Learning to See. Most importantly for us, Lean concepts were applied to software delivery in Mary and Tom Poppendiecks seminal work Lean Software Development. Applying a value stream map to the delivery pipeline was perhaps most strongly highlighted in Humble and Farley’s 2010 work Continuous Delivery.

When a team conducts a value stream mapping exercise there are some immediate benefits. The first thing is that we immediately connect with the customer. Our focus is on determining how quickly we can get something new into the hands of our customers. We also visualise the flow of work through the system, which allows us to deepen our knowledge of the system as a team. We begin to remove the I wonder what our such a person is up to? type questions and start to realise that all of our actions have some impact on the delivery of the item of work.

Perhaps the biggest benefit of conducting a value stream mapping exercise is that we can begin to use it for initiating continuous improvement initiatives. In fact, I believe this is one of the best tools for driving continuous improvement. Using value stream maps allows us to make better decisions on where we need to start improving. As the theory of constraints goes:

Any improvement not made at the bottleneck is an illusion

As such, conducting improvements on your value stream blindly might not actually be improving anything…

The Three Ways

The first way of DevOps, described in the DevOps Handbook and The Phoenix Project, teaches that we need to begin to see the system of work as a whole. This means that we need to begin to think about more than just the work we conduct, be that as a developer, an analyst, a QA or an ops engineer. A value stream map can be the visual representation of the whole system of work.

The second way of DevOps talks about providing fast feedback when applied to our value stream, this means understanding things like lead and cycle time. A leading indicator of bottlenecks is where work is queuing, or waiting to be done. If we don’t have these metrics yet, we can see on our value stream map and the exposure of these metrics can be our first improvement effort.

The third way of DevOps talks about continuous experimentation and learning. A value stream map can be the source of truth to drive continuous improvement of DevOps practices and principles of your value stream. Coupled with a scientific approach, we can systematically, step by small step, move towards our challenging true north goal.

Using what the Lean community terms Plan-Do-Check-Act, or more understandably, Prediction-Test-Data-Evaluate in Rother’s Toyota Kata Practice Guide, we can give ourselves a framework to continuously move towards delivering more value, more safely.

Defining Value

We’ve spoken a little bit about improving the delivery of value, but we’ve not done much to define exactly what value means. This is a difficult topic, there is even a whole book dedicated to it, The Art of Business Value.

[Business value] isn’t something that is a given or that Agile teams can’t question. It is something that we can all talk about and ask questions about, something we can debate and contribute to. It is something we must talk about, because we can’t just deliver features and expect business value to pop out of them

Suffice to say, the value is in the eye of the beholder. In our case, as a development team, we can consider the following metrics as leading indicators to our delivery of value as defined in the Accelerate State of DevOps Report and Accelerate:

• Deployment frequency
• Change lead time
• Change failure rate
• Mean time to recovery

We can consider the first two as measurements of throughput, and the final two as measurements of stability. We’d be hard pressed to find better metrics to define ourselves against. Adopting these metrics into our true north goal gives us a good target to aim for in improving our value stream.

To discover whether what we’ve delivered actually carries value, we need those discussions with the business to define measurable success metrics. We then need to build in how we track whether we’re delivering value.

Moving Forward

The most dangerous phrase a person can use is “We’ve always done it that way”

Adopting the use of value stream mapping can be an enlightening experience for any team or business delivering software. If nothing else, it can increase the visibility of just what it takes to get something into the hands of our customers, increase empathy with those in our value stream and deepens our understanding of the system.

From these humble beginnings, a value stream map can be used as our yardstick to how much progress we’re making towards our true north.