Cycle time is one of the most useful measures available when it comes to improving your software team’s productivity. 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 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.
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 release 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.
However, unlike most catchall measures, cycle time gives you results in real time. That means you can catch and fix issues as they occur rather than missing deadlines.
For example, is your review time higher in the current iteration? That may be a sign that you need to get more information to the development team from product management.
The upshot is that 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.
Tactics to Reduce Cycle Time
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.
For example, if the the coding time is too high, you can look at breaking work into smaller units. If that’s not a problem, you can investigate the amount of re-work and code churn. Maybe someone assigned the feature to the wrong developer, or the person describing the feature didn’t communicate well. The issue may be something you can address in a quick Q&A session.
2. Improve Workflows With Alerts and 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 handover so teams always receive communication, packages, and data 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 Teams. What these are can be project and workflow specific. However, it’s best to focus on areas that commonly have bottlenecks, such as handovers. 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.
In addition, you can make alerts that use multiple metrics together. On the flip side to pull requests being held up, if a review of hundreds of changes takes under a minute, it may not have been reviewed in enough detail. You can set up automation to pause the release until the request is checked again. Doing so can help you avoid a bad release and all the relevant re-work. These alerts allow you to fix problems in real time rather than waiting for them to become bigger.
LinearB enables this kind of workflow improvements by automatically sending alerts for high-risk branches, PRs merged with no or little review, PRs waiting for review, and PRs stuck in review.
3. Parallelize and Asynchronize
There are three major requirements that allow you to introduce parallelization and asynchronicity into your software development.
- The first is clear and easy-to-understand communication and documentation. If you’re switching from Task A, to Task B, to Task C, and back to Task A, it must be easy to pick up each and run with it.
- Second, having an easy-to-find list of available items helps team members transition between work tasks while waiting for feedback.
- Finally, reducing iteration size makes parallelization easier. For example, your team members can test Iteration 1 at the same time as they’re developing Iteration 2 and defining requirements for Iteration 3. Reduced iteration sizes also help ensure that team members can review pull requests more quickly. That’s because they contain fewer, more focused changes.
Be sure to check out LinearB’s mission page for more on asynchronous development and why it’s important for hybrid remote dev teams.
Every iteration has unique challenges. You and your team members can quickly solve most of them as soon as you identify them. However, we all have ideas that don’t work out. Has a change in the cycle led to gradual improvement over a few iterations? Or has a change had no impact or even the opposite effect?
If you have a little mad scientist inside that’s wanting to get out, this is your chance to set them free.
Try things as the iteration is going on. That’s why cycle time being in real time is so important.
Let’s look a couple of examples.
- Maybe you tried adding a note to daily standup meetings to remind team members about outstanding pull requests. This gradually improved cycle time until you no longer had to include the reminder.
- Or it could be that you designed an alert for when high-priority bugs come in. You thought this would get them through the pipeline faster. However, in the real world, team members began picking up only the high-priority bugs. This change looked good at first glance, but it actually led coding time on other features to balloon.
If you’ve made it this far, the next logical question is probably: How do I start measuring my software development cycle time?
The LinearB platform is designed to correlate and reconstruct 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 account and get your team’s Cycle Time breakdown in minutes.