Measuring DevOps Success in Your Software Delivery Pipeline
Source – news.sys-con.com
When it comes to measuring the success of your DevOps rollout, it can be challenging to identify the right metrics that will provide intelligence while avoiding the trap of vanity metrics that indicate action—but not necessarily progress—towards the outcome you’re looking for.
In my experience, the most valuable metric of all is the lead time between when you make a commit in source control and when that change makes it to your consumers. Some very mature organizations have even been able to link this metric to validated learning or planned outcomes in production (i.e., user engagement, revenue, or even a pivot decision). This sort of full-cycle measurement closes the DevOps build-measure-learn loop and gives you unparalleled insight into the performance of your overall delivery metrics.
DevOps by the Numbers
How to Approach the Measurement and Metrics of Your Continuous Delivery Transformation
This sort of advanced metric, however, can be very difficult to implement; it often requires process, technology, and cultural changes within your team to be successful. If your organization is just beginning its DevOps journey, it can be unclear where you can start getting value immediately. For teams at that point, I have listed a few ideas here that are other good areas to begin.
When and where is activity occurring in my delivery pipeline?
Measuring when individual parts of your delivery pipeline are heavily utilized can offer surprising insights on when teams may be overloaded. If your source control, build, and testing systems remain idle until late in your sprints then suddenly become overwhelmed with changes, it would suggest changes to your planning or software development process could yield real benefits. For example, implementing something like Kanban into your development process could smooth the flow of work into the system and resolve what teams may be experiencing as late-sprint chaos. Within XL Release, this sort of metric can be clearly visible within the longest task/phase reports.
What kind of activities across systems are failing and how frequently?
The reliability of the various technical processes within your pipeline can have an outsized effect on the flow of changes through your system—not to mention team morale. Unreliable tests, flaky build systems, or other components of your pipeline that are unreliable will quickly form a bottleneck to teams looking to deliver more quickly and independently. Keep a close eye on these to ensure you aren’t tripping over your own feet.