How do you measure the effectiveness of your DevOps pipeline? How do you know if you are improving? We take a look at a simple way to measure this to chart your progress
At my current project, we have been trying to get the company more into the DevOps mindset so that we can release smaller chunks of work more often. This has been done with varying degrees of success, but change like this requires turning the ship around, which isn't always a quick process.
I recently stumbled onto an article on how to measure the effectiveness of your DevOps. After reading it, most of it seems pretty obvious, but I thought other people may find it useful and get some value from it.
A Few Simple Questions
A simple way to understand how effective your DevOps process is to simply ask yourself the following questions:
- How long take from the customer asking for the item of work to its delivery?
- How long does the team take to deliver the work once it has started?
- How often, as well as what percentage of your time, do you spend working on production defects?
- How often are deployments done?
- How often do you have issues in your deployments?
Digging into these questions, and possibly using the 5 Why's Technique will help you to understand where the actual problems lie, if you don't know them already.
Lead Time & Cycle Time
In order to measure how you are doing in DevOps, we can take a look a two main metrics, namely Lead Time & Cycle Time
- Lead Time - This is the time from when the requirement is created to the point when it is delivered, and is a view from how long it takes from the customers perspective.
- Cycle Time - This is the time from when the team starts on the requirement to when they deliver it and is a view from the teams perspective. You want this value to be more or less the same to show that you are delivering at a reliable pace.
If either of those times are long, you need to understand as to why the work is piling up or why is progress so slow? It could be that the customer is coming up with a lot of good ideas, or that the team is even moving to slowly as they don't have the required knowledge, or are just simply under staffed.
Once you start to measure these times it can give you a view as to how the team is improving.
It's A Culture Thing As Well
I recently went to a client who wanted some assistance with the automation of their environment. He was talking about some of the culture issues that they were facing. and then I realized that in some situations the culture change may be more difficult that the automation itself.
People are typically adverse to change, especially after they are used to doing this a particular manner for a long period of time. In these situations I would try to explain to the team what the end goal is and how this fits in to the overall picture. Just the simple act of letting people understand why can go a long way. Ultimately, you need everyone to get on the bus with you, else the process is bound to fail.
Until next time...keep learning!