← Back to blog

How to Reduce Cycle Time in Software Delivery: 4 Tactics

Learn how to reduce cycle time with insight, automation, and team working agreements.
March 5, 2021 • Michael de Ridder

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?

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.

Cycle time benchmarks

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.

Get context around cycle time bottlenecks in one click. Diving into your data has never been this easy. Get started with our free-forever account today!

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.

Pr left on read? Not anymore.
Promote your pull requests to merge 10x faster. Get started with our free-forever account today!

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.

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.

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.

Linearb team goals dashboard

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!

How dama financial improved cycle time with linearb
Want to learn more about improving your cycle time? Check out how our customer Dama Financial reduced their cycle time.

Further Reading

Join our community of data-driven dev leaders

Each week we share stories and advice from engineering and product leaders striving to be better for their teams.

LinearB may send you email occasionally about how you can optimize productivity.
We will not share your information with anyone. Ever.