Cycle time is a measure of how long it takes to get a new feature in a software system from idea to execution in production. In agile circles, we try to minimize cycle time. We do this by defining and implementing very small features and minimizing delays in the development process. Although the rough notion of cycle time and the importance of reducing it is common, there are many variations on how cycle time is measured.
A key feature of agile software development is the change of a
waterfall processwhere work is decomposed based on activity (analysis, coding, testing) in an iterative process where work is based on a subset of functionalities (simple pricing, volume discounts, valuable customer discounts). Doing this creates a feedback loop where we can learn by introducing small features to users. This learning allows us to improve our development process and allows us to better understand where the software product can bring value to our customers.
This feedback is a key benefit of an iterative approach, and like most of these feedback loops, the quicker I get it, the happier I am. Therefore, agile people put a lot of emphasis on how quickly we can get a feature through the entire workflow and into production. the phrase cycle time It is a measure of that.
But here we run into difficulties. When do we start and stop the clock in cycle time?
The easiest and most simplistic time to stop is when the feature is put into production and helping its users. But there are circumstances where this can get confusing. If a team is using a Canary launchShould it be used by the first cohort or only when it is disseminated to the entire population? Do we count only when the app store has approved its release, thus adding an unpredictable delay that is largely out of the development team’s control?
The start time has even more variations. A common marker is when a developer first commits to that feature, but that ignores the time spent on preparatory analysis. Many people would go further back and say, “when the customer first gets the idea for a feature.” This is all well and good for a high priority feature, but how about something that’s not as urgent and will therefore sit in a triage area for a few weeks before being ready to go into development? Do we start counting down the clock when the team first puts the feature on the card wall and start seriously working on it?
I also get into the phase delivery timesometimes instead of “cycle time”, but often together, where people make a distinction between the two, often based on a different start time. However, there is no consistency in the way people distinguish them. So in general, I treat “lead time” as synonymous with “cycle time,” and if someone uses both, I make sure I understand how that person makes the distinction.
All different cycle time frames have their advantages and it is often useful to use different frames in the same situation to highlight the differences. In that situation, I would use a distinctive adjective (e.g. “first commit cycle time” vs. “idea cycle time”) to differentiate them. There are no generally accepted terms for such adjectives, but I think they are better than trying to create a distinction between “cycle time” and “lead time.”
What these questions tell us is that cycle time, while a useful concept, is inherently slippery. We must be careful when comparing cycle times between equipment, unless we can be sure that we have consistent notions of their stop and start times.
But despite this, thinking in terms of cycle time and trying to minimize it is a useful activity. It is usually worth creating a value stream map that shows each step from idea to production, identifying the steps in the workflow, how much time is spent on them, and how much time is expected between them. Understanding this workflow allows us to find ways to reduce cycle time. Two commonly effective interventions are to reduce the size of features and (counterintuitively) to increase Loose. It’s worth working to understand the flow and improve it because the faster we get ideas into production, the faster we’ll reap the benefits of new features and get feedback to learn and improve our ways of working.
Expressions of gratitude
Andrew Harmel-Law, Chris Ford, James Lewis, José Pinar, Kief Morris, Manoj Kumar M, Matteo Vaccari and Rafael Ferreira discussed this post on our internal mailing list.
