If DevOps cycles are something you work on or are interested in, join the discussion on this topic by signing up for Mindset’s DevOps Roundtable on Thursday December 3rd.
In the world of DevOps, cycle-time is the way we work to achieve our goals. This isn’t unique to DevOps, but is a key concept in many areas ranging from the martial applications to manufacturing to the design thinking process. Almost every complex endeavor involves cyclical, iterative processes that we work to improve.
Development and operations is no exception. If we look at some of the primary DevOps metrics, we see cycle-time measurement is central. Metrics such as Mean Time To Recovery, Lead Time for Changes, and Deployment Frequency are some of the most popular measurements of DevOps effectiveness. In Scrum, the time-boxed sprint is the lifeblood of the process and measurements of velocity are some of the most important health-indicators of the process.
There are a lot of observations that can be made about cyclical processes, but I wanted to point out a couple that have sprung to mind lately.
Nested cycles
Each cycle is made up of cycles and is itself part of many larger cycles. Therefore, improvements to a cycle have knock-on effects within the rest of an organization. Some cycles are key points of leverage (or bottlenecks, depending on how efficient the cycle is).
For example, the Lead Time for Changes metric is important in itself because it measures how quickly we can move changes and fixes through a development and deployment process. But the process of developing and deploying a change is also a key component of a host of business and technical cycles, from a designer working to run an A/B test to influence a key product decision through to business measures like return on assets or employee retention.
Just think, employees like to see their impact, but if you measure an organization’s lead time to changes in years (and yes, this is not uncommon in enterprise software), then employees quickly become frustrated or resigned, and may move on to greener, more fulfilling pastures. Similarly, if a business invests money in improvements, through purchase of assets or hiring an employee, how long will it be before a return on that investment can be realized? Lead Time for Changes is a key influence on the answer to this question.
When thinking about cycles to focus on, think about which ones influence the most other processes. What are the bottlenecks?
Multiple measures
Relatedly, there is more than one way to improve a cyclical process. Types of measures fall into a few categories:
- Frequency – These are measures of how often a process happens. Deployment frequency is one of these types of measures.
- Duration – How long does a process take from start to finish? Lead time for changes is one such measure. Mean time to recovery is another.
- Throughput – How much stuff can we move through a process? In scrum, story points measure throughput, for example.
These measures are obviously interrelated. None of them are exactly functional inputs of the others, but each of them influence each other. In many scenarios we will not be able to or not want to change one measure. However, we will want to improve another. Choosing what to measure is very important to the process of improvement. Choosing the wrong measure and stymie improvement or even lead to regression.
Join our ongoing discussion series on DevOps to learn more and share your experience on this and other topics. Our next Roundtable is on Thursday December 3rd and we look forward to seeing you there.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
