101: What is Continuous Improvement?
Hi, I'm Andrea Crawford with IBM Cloud. We're going to talk about continuous improvement.
This is often the last part of the DevOps wheel, but a lot of times neglected by clients.
Let's talk about continuous improvement and what the benefits are.
First of all, when we're able to continuously improve, the application delivery pipeline
here, weÕre able to quantify the return on investment. What I mean by that, is when we
invest in automation tools, modifying our governance process, and investing in our people,
to change the way that we deliver applications, weÕre able to quantify the velocity and the
quality that we achieve. This is all about understanding with empirical data how we're
getting faster, and how were improving on the number of defects that are actually getting
deployed into production.
But one of the other benefits of continuous improvement is all-around customer or consumer
experience. So, this is the digital experience. And we need to make sure that we are getting
better at, not only becoming faster and delivering with less defects, but are we resonating with
our consumers in terms of the products that are coming out of this pipeline?
So, with continuous improvement we really have to define some Key Performance Indicators,
or ÒKPIsÓ, to quantify our return on investment.
So, some of these KPIs might be things like ÒDeployment FrequencyÓ. Deployment frequency
is all about understanding the number of deployments to production that are measured in days, weeks,
or months. We also have something called delivery lead time. Delivery lead time is all about
how long it takes to get from code all the way through to deployment, and this is typically
measured in number of days. There are also KPIs around Òchange volumeÓ, which measure
the number of story points that are actually packaged into releases that make it to production,
and we can also define success around ÒMean Time to RecoveryÓ, and this is all about
how long it takes once a defect is found in production - how long it takes to figure out
that you've got a defect, and then type it back in to the software delivery lifecycle
so that a fix can be coded, and so that it can be deployed back into production. So,
this is Mean Time to Recovery, so it's deploy to deploy.
To sum all this up, use-cases are really lack of KPIs, lack of or absence of instrumentation
in this pipeline to actually gather the empirical data to measure how fast, or how defect free
we are, so Òno instrumentationÓ. And then we have the lack of being able to trace investment
dollars to the return on investment. If you have issues with any of these scenarios over
here, you might need to improve your continuous improvement strategy.
And so, as a result, we really need to be able to define KPIs to measure our success
so that we can quantify return on investment - and in order to do that we need to be able
to instrument the pipeline to gather empirical data on how long it takes applications to
get from all of these phases, one to another. And then additionally, once we have that empirical
data, weÕre able to identify the bottle necks, where weÕre slowing down, and that will give
us data-driven decisioning and information that we can use to improve on those bottlenecks.
So, as you see, continuous improvement as all about people, process, and tools.
Thanks for watching this video. If you have any questions or comments be sure to drop
a line below. If you want to see more videos like this in the future, be sure to like and
subscribe.