Cycle time is one of the most useful measures available when it comes to improving your software team’s productivity. And aiming to reduce cycle time is not just a vanity metric to make engineering orgs look good to execs and stakeholders. It’s something that contains a lot of information that you can unpack and dig into to remove bottlenecks, streamline processes, and support developers.
However, the other side to such a dense metric is that it can be daunting. There are so many things you can tweak in a software development life cycle, but what will actually have a positive effect on productivity?
In this post, I’ll give you four tactics you can use to reduce cycle time. I’ll start by recapping what cycle time is in the context of software delivery and cover why it’s so important. Then I’ll take you through some tactics you can try so you can reduce cycle time in your organization. In doing so, I hope to make the metric more approachable and less daunting.
Are you ready? Let’s cover the basics first.
Table of Contents
- What Is Cycle Time?
- Why Is Cycle Time Important?
- 4 Tactics for Cycle Time Reduction
- Start Reducing Your Cycle Time Today
What Is Cycle Time?
Before looking at methods to reduce cycle time in software delivery, it’s important that we’re on the same page about what cycle time is. So in short, software development cycle time measures the amount of time from work started to work delivered.
Software development cycle time begins when a developer first starts working on a new feature. It ends when that feature gets released into the hands of users.
Within cycle time, there are a number of phases. The first is coding time (sometimes affectionately called “fun time”), and the last is deploy time. If your company has already invested in continuous delivery, then merge time is effectively equal to cycle time.
Why Is Cycle Time Important?
Software development cycle time is a bit of a catchall “super metric” because it contains so much information within its phases. It shows the efficiency your software development team has when it comes to getting value into the hands of customers.
You can measure efficiency and trends over time for different teams, iterations, and products. You can identify bottlenecks in the delivery process and immediately work on ways you can fix them.
For instance, is your release time consistently taking too long? In that case, it might be time to invest in continuous delivery.
As a result, cycle time might be the most important metric in software development.
4 Tactics for Cycle Time Reduction
The key to reducing cycle time lies in detecting and eliminating bottlenecks. Each of these four tactics will help you do just that.
1. Measurement Leads to Improvement
This one might sound incredibly simple and obvious, but it’s something that people often skip. If you don’t know what’s slowing down your cycle time, you might apply the wrong solution. So the first step is to make sure you’re measuring your cycle time and its component phases accurately. This means you need to get data directly from the source (for example, GitHub or Bitbucket) and combine it with metrics from your project management software.
Once you’ve done so, you’ll be able to look into each of the phases for the current iteration and compare it to prior iterations and other development teams. Then you can drill in further on any bottlenecks you find.
2. Improve Workflows With Automation
The first step of automation is everyone’s favorite: continuous integration and continuous deployment. I’m sure I don’t need to go into these in much detail. It’s enough to say that using CI/CD to automatically manage releases saves a huge amount of manual work.
Beyond CI/CD, look for manual steps and communication that you can streamline with automation. For example, automate your code review process so teams always receive communication and context in the same format.
As you automate, it’s useful to also look into configuring meaningful alerts, ideally through a system your team uses every day, like Slack or MS Teams. It’s best to focus on areas that commonly have bottlenecks, such as the code review process. For example, alert the relevant people when a pull request has been submitted. And alert them again if they don’t merge within a set timeframe.
Our developer bot, WorkerB, enables this kind of workflow improvement by automatically sending team and personal notifications for things like high-risk branches, PRs merged with no or little review, PRs waiting for review, PRs stuck in review, and many more reminders aligned to your custom Team Goals.
3. Implement Continuous Merge
It’s time to address the next big challenge for developers. Actually getting code merged.
Our team at LinearB Labs analyzed millions of PRs from thousands of dev teams across all sizes of organizations, and we found that the average cycle time is about 7 days. And we found code sits in the PR review process for 5 out of the 7 days. Even worse, we found that the majority of those 5 days resulted in an “LGTM” type review. But not all PRs are equal, and they shouldn’t be treated equally.
It’s time to move beyond CI/CD to a CM/CI/CD approach.
Continuous Merge (CM) is the practice of improving merge efficiency by classifying pull requests based on change size and complexity. Automating the merge path based on the unique merge conditions allows work to flow more efficiently and ultimately reduce cycle time.
We’re solving this problem with the first stand-alone continuous merge tool, gitStream.
Continuous merge using gitStream starts with creating review automations for your code in a .cm file. Some PR’s are just image or docs changes that could be merged automatically; while others are modifications to key parts of the codebase that need review from a subject matter expert or more than one reviewer.
Each of these unique cases can be customized in your repo’s .cm file.
Want to learn how to implement custom dev workflow automation to cut code review time by up to 40%? Watch this hands-on workshop to set up the free gitStream tool to automatically:
Classify and route pull requests Add estimated review time to PRs Apply custom rules
gitStream product lead, Ofer Afias, will take you through a live demo of the three core functions when getting started with gitStream workflow automation to scale your team efficiently and improve your developer experience.
4. Experiment
Every team and iteration has unique challenges. This is why gitStream, Team Goals, and WorkerB are completely customizable.
We have published an Engineering Metrics Benchmarks study so you can compare your cycle time against industry standards. And we recommend you establish working agreements within each team and set realistic goals, like improving one tier per quarter. But how you get there should be unique to each team in your org.
So experiment, track progress, and iterate. And most importantly celebrate success! Our Team Goals dashboard is a great way to track progress. And we recommend you create a ceremony or use your sprint retros to reflect back on if you’re meeting your goals and ultimately reducing cycle time.
Start Reducing Your Cycle Time Today
If you’ve made it this far, the next logical question is probably: How do we start reducing cycle time immediately?
The LinearB platform is designed to correlate Git, project, and release data so you get real-time project insights and team metrics with zero manual updates and zero developer interruptions. Sign up for a free-forever account and get your team’s cycle time breakdown in minutes.
But don’t just take our word for it!
