Master Cycle Time to Improve Software Development

What is Software Development Cycle Time?

Software development cycle time refers to the period of time from an engineer’s first commit to the deployment of code. Some teams also refer to this period of time as lead time. Cycle time or lead time indicates the time taken to complete a particular dev task. 

Cycle time is often used to infer a dev team’s process speed. It measures a dev team’s efficiency and ability to deliver working software within a defined time frame.

Measuring cycle time for teams helps leaders get visibility into the speed of each team, time taken to complete particular projects, and the overall performance of teams compared to each other and against the rest of the organization. Additionally, optimizing cycle time can help leaders build a positive team culture and can boost innovation and creativity in engineering teams. Cycle time is a lagging indicator, a metric that confirms patterns that are in progress. This means that cycle time isn’t a productivity measurement tool, rather it can be used as a signal of underlying issues in a team. 

Since cycle time refers to the speed of team performance, most teams strive to attain a low cycle time within which their teams are able to achieve optimum efficiency. The Accelerate State of DevOps Report research of 500 engineering teams suggests that the top 25% of successful engineering teams achieve a cycle time of 1.8 days, while the industry-wide median is 3.4 days, and the bottom 25% of teams have a cycle time of 6.2 days. 

How to Calculate Cycle Time?

To calculate cycle time, you need to determine the total time it takes to complete one cycle of a process or task. 

General Formula to Calculate Cycle Time:

Cycle Time = Total Production Time / Total Number of Cycles

• Total Production Time: This refers to the time required to complete all the necessary steps to produce one unit or complete one cycle of the process.

• Total Number of Cycles: This represents the total number of units or cycles produced within a specific time frame. It could be the number of units produced in an hour, a day, or any other defined period.

Why is Cycle Time Important?

Cycle time is a good indicator of not just the health of your software projects, but overall engineering effectiveness as well. Quick delivery of features loosely translates into quicker revenue, better cashflow, and a healthy bottomline.

Moreover, shorter cycle time is also an indication of streamlined workflows where devs aren't just firefighting anymore. Short cycle times keep your team engaged, motivated, and churning out their best work, leading to higher engineering productivity, and well-being.

Here's why cycle time matters to engineering teams:

1. Slower Time To Market, And Fear Of Losing Out To Your Competition

Every day a feature sits locked in development is a day your competitors are leaving you behind. Amazon was losing out on 1% of their sales before they amped up their cycle time to reduce deliveries from 6 hours to 10 minutes. Imagine the lost opportunities and stagnant growth associated with a sluggish cycle time.

The market moves fast, and slow teams miss out on capturing emerging opportunities. Moreover, your rivals get to users first, potentially shaping market preferences, and you stand with a potential threat of being locked out. On top of it, missed deadlines and delayed features damage customer trust and brand reputation, there you lose your CX advantage to your competitors.

2. Poor DevEx

Long waits for deployment, testing, and feedback breed frustration, disengagement, and eventually, burnout. Studies show a 27% rise in burnout rates for teams with lengthy cycle times. This frustration spills over, even tanking the morale of the overall engineering team. A high cycle time means the team isn't able to diagnose the impediments that are blocking the devs from doing their best work.

When things move slowly, it's easy for devs to feel detached from the impact of their work.

3. High Rework, and Code Churn

The pressure to "hurry up and get it done" breeds hasty, poorly-written code. This becomes a vicious cycle: rush to deploy, encounter bugs, rewrite code, repeat. All in the bid to control an inflated cycle time.

This technical debt translates to future bugs, constant firefighting, and delayed releases. It also means your features stand at the risk of becoming obsolete or irrelevant, improving the instances of wasted effort and resources.

Cycle time is not just about speed. It's about balancing speed with quality and ensuring you're delivering critical features to end customers.

Impact of High Cycle Time

Risk of Code Quality

When cycle time is high, a natural eventuality is for more work remaining in a work-in-progress status.  As sprints close and deadlines loom, engineers end up juggling between several unfinished tasks, increasing the risks of errors and writing buggy code. At the same time, the longer it takes to merge code, the more context is lost by authors. These incidents impact code quality and increase the chances of missing edge cases. This is a vicious cycle, when it takes longer for engineers to revisit the code after review, the longer it takes to fix the code, in turn increasing cycle time.

Risks to Delivery

Increased cycle time inevitably leads to tasks overflowing sprints that delay delivery. As sprints remain open over time, it leads to several critical tasks remaining unfinished and hence impacts the speed of delivery for the team. Furthermore, the effort to review and rewrite incorrect or inefficient architecture or poor code, the loss in context due to long gaps to pick up reviews, and the context switch between WIP tasks caused as a result of high cycle time severely impact the productivity of the entire team and the quality of the code.   

Bad Employee Experience

As code stays in WIP status, engineers shift between several tasks, increasing context switches and the associated lull in productivity. As the habit stretches, engineers find themselves context-switching between different git branches and pull requests while working under the pressure of delivery timelines from the product team. 

In most teams, cycle time increases are attributed to the bottleneck caused by reviewers. As more review requests pile up, it adds to the pitfalls of context switches, poor workload management, and threatens well-being. These circumstances compound into individuals feeling increased stress, anxiety, exhaustion, and eventually burnout. 

When engineers and their teams work under such pressure, within a matter of time, they begin missing schedules and deadlines, often delivering code that underperforms. This leads to team members feeling unsatisfied, often impacting engagement and morale.

[Read: How to Delete a Branch in Git]

Drawbacks and Problems of an Extremely Short Cycle Time

Though a cursory glance at a very low cycle time metric for a team might be an initial reason to be buoyant of the team’s performance, managers and leaders must pay attention to such instances. In almost every case of very low cycle time, which is lower than industry averages, we see that the time to review is considerably low. For engineering leaders, this is a potential “gotcha” moment since very low cycle time could be a possible signal of low-quality code reviews. Managers must implement checks and workflows that ensure thoughtful and detailed reviews for all PRs.  

What Are the 7 Factors That Cause High Cycle Time?

While managers and leaders are cognizant of the importance of cycle time, they aren’t always equipped with data for visibility into why their team’s cycle time might be higher or lower than optimum. Understanding the processes that constitute cycle time and delving into the components that make up cycle time can help leaders make decisions that positively affect developer happiness, productivity, and overall team performance.

1. Large PRs

Large-sized PRs take longer to code and hence they go unopened for too long, increasing the time to open a PR. For instance, most teams target PR sizes to be under 300 changes and when this threshold increases, the time to open the PR becomes longer. Even when large PRs get opened, they get stuck without being pushed to the review stage since most reviewers are apprehensive about reviewing large PRs for two reasons: 

1. A large PR signifies a large effort on the part of the reviewer. It requires heavy and intense work for which the reviewer has to plan and reorganize their existing workload substantially to accommodate a large PR review. 
2. Large PRs are infamous for their ability to introduce several new bugs. Hence reviewers view them as high-risk tasks. 

2. Low Seniority or Expertise

High coding time and high time to review are often signals of low expertise within a team. When teams lack expert engineers or when junior engineers are not onboarded with a thorough orientation, learning, and development process, it reflects on the cycle time of the team. Most junior engineers or engineers with low domain expertise take longer to create a PR, and have to go through multiple back-and-forth reviews, leading to a high number of edits, rework, and increased time to merge.

When a team lacks senior engineers and experts capable of complex reviews, the pickup time suffers. Reviewers without the necessary expertise take longer to open PRs and longer to review. This adds to a reviewer’s workload and becomes a bottleneck to the team. 

3. Lack of Documentation

Documentation in code and coding guidelines like code comments are a great practice that is unfortunately overlooked too often. Documentation can help reviewers and future collaborators review and work on code faster and better, reducing pickup time and rework time. Coding guidelines help authors to have the pull requests in a better state at the get-go. They also help reviewers avoid multiple back and forth on basic guidelines and workflows. This documentation is especially helpful in cross-team collaboration or cross-functional collaboration on code owned by other teams. Different teams follow different patterns of code and documentation helps maintain consistency. A readme specific to a codebase about coding patterns or supporting items like how to and where to add logs, and emit metrics, and approval criteria, etc., can go a long way in helping teams optimize pickup time and review time. 

4. Low Involvement & Low Responsiveness

When reviewers lack engagement and involvement, they tend to not review code despite having enough time and resources. Similarly, when engineers are disengaged and slow to respond to comments, it increases the time a PR takes to go through a complete review. 

5. High Workload

An unmanaged and high workload can lead to engineers struggling with several WIP PRs, inevitably reporting a longer time to code and rework. For reviewers, the volume of review requests piles up towards the end of a sprint rather than a gradual inflow of PRs leads to them getting overwhelmed. This constrains reviewers’ own coding time and also leads to a high number of PRs being merged without review, thereby risking code quality. 

As reviewers struggle with completing their own code, the reviews, and the rework, the team suffers a high cycle time. 

6. High CI/CD time

Engineers might be waiting on builds to complete and tests to pass before the PR is ready for review, thus leading to an increase in cycle time. The process becomes even more inefficient when engineers have to make changes after every review and wait for a drawn-out and slow CI/CD that prolongs the time to merge. Not only does this increase the cycle time, but it also leads to feelings of frustration in contributors. 

7. Lack of Pre-commit Sanity Checks

When teams do not implement simple sanity checks before creating PRs (like linting and test code coverage) they lead to avoidable nit pics during code reviews  (where the reviewer may have to spend time pointing out formatting errors or test coverage thresholds that should have been covered by the author by default). 

How Can Managers Combat High Cycle Time?

PR Size matters

The first step to reducing cycle time is addressing the issue of large PR sizes as a team. Equipped with quantitative metrics about batch sizes, leaders can initiate open feedback conversations and retros to discuss issues such as breaking down PR sizes that enable teams to merge code at a consistent pace. Team leads can ensure that PR sizes do not grow large due to expanding the scope of work. 

The team can also come together to acknowledge the complexity of new work, potential risks, and instances of rework. This can help team leads and managers to optimize processes and workload for better performance. When leaders notice individual developers with high levels of context-switching, they can address issues and inefficiencies in data-driven 1:1 meetings.   

Better Workforce Planning 

Team leads must ensure that junior engineers are onboarded, adequately trained, and equipped with the right tools and resources so that they can contribute to the team’s performance quickly. Leaders must also ensure that teams are composed of a balance of junior and senior staff to create an efficient work environment and foster a culture of learning and growth.

Incentivize Reviews 

By keeping PR sizes small, managers can ensure that peers pick up review work without fearing the usage of large periods. Managers can also distribute review workload fairly using quantitative input into existing workload management. Emphasizing code reviews across the team and rewarding a culture of code reviews can help more hesitant peers to pick up review work alongside their coding. Better training and better tools can also help developers to become confident in their reviews, helping them become more enthusiastic about review work.  

Better Workflows

Deployments should be consistent, reliable, and optimized for smooth operations. To achieve such a cadence, managers must ensure that their teams are provisioned with the right tools, communicate regularly with their teams regarding processes and bottlenecks, and create team environments that promote learning and development to strengthen the review process. 

How Optimal Cycle Time Impacts Individuals, Teams, and Businesses?

Impact on developers: An optimal cycle time directly impacts developer happiness and satisfaction. Several engineers and managers often report their experience of feeling a sense of achievement, satisfaction, and purpose after completing projects and pushing code to merge. When engineers are able to merge more code because of efficient practices, it allows more time to work on innovation and newer projects. All these lead to better individual satisfaction and happiness. 

Impact on teams: Measuring cycle time can help understand a team’s delivery cadence and help maintain stable efficiency metrics. When leaders strive to optimize cycle time, they are able to rebuild tooling resources and processes to adequately provision their teams. When cycle time climbs upwards, team leads can pre-empt threats to productivity by reorganizing their teams and workload to optimize performance. These preemptive steps can lead to a team succeeding in achieving its goals. 

Impact on businesses: Business leaders can use the cycle time metric to align larger business requirements with engineering capabilities. When business goals include shipping more products or faster updates, studying the cycle time of existing teams helps leaders strategize resource needs and allocation. This encourages better, faster, and more data-driven decisions. Optimizing cycle time can help businesses complete more projects and resolve issues faster. This makes businesses faster to market, leaving their customers and stakeholders happier and satisfied.

Cycle time as a stand-alone metric offers immense insights into team performance, individual productivity, and business success. However, when cycle time is studied within the constellation of other metrics, the potential of engineering practice is greatly amplified because of the possibilities of optimization, alignment, and engagement. Modern engineering teams must adopt a practical and systematic approach to measuring team performance using a framework of metrics that are aligned with business goals. When this data-driven view is combined with qualitative input from good communication practices, the potential of engineering teams can skyrocket. 

Hatica equips engineering teams with granular visibility into team cycle time alongside 60-plus other metrics enabling them to reduce bottlenecks to accelerated delivery and achieve a better developer experience. Learn how Hatica can help you build better engineering teams. Request a demo →

FAQs

1. How Long Should Each Phase Take in SDLC?

The duration of each phase in the Software Development Life Cycle (SDLC) can vary depending on the project's complexity and requirements. Here's an approximate range for each phase: Planning: 1-4 weeks, Requirements gathering and analysis: 2-6 weeks, Design: 2-6 weeks, Development: 4-16 weeks, Testing: 2-8 weeks, Deployment: 1-4 weeks and Maintenance: Ongoing. 

2. What is the Maximum Possible Cycle Time?

In the Software Development Life Cycle (SDLC), the maximum feasible cycle time refers to the greatest time it might take to complete a full iteration or cycle of the development process. It fluctuates according to the project's complexity and scale, as well as other aspects such as team efficiency, resource availability, and unanticipated problems.

3. What is the Difference Between Cycle Time and Lead Time?

Cycle time is the time it takes to complete a single iteration or cycle of a process from start to finish. It quantifies the amount of time spent on activities that bring value. Lead time, on the other hand, is the overall time it takes from the time a request or job is begun until it is delivered to the client.

4. Why Reduce Cycle Time?

Reducing cycle time is crucial because it allows for faster delivery of products or services, enables quicker response to market demands, improves efficiency by eliminating waste, increases productivity, and enhances customer satisfaction by providing timely and valuable solutions.

5. What is the Formula for Cycle Time?

The formula for calculating cycle time is:

Cycle Time = Total Production Time / Total Number of Units Produced

To calculate the average time it takes to complete one cycle or unit, divide the total production time by the number of units generated during that period. Cycle time is typically stated in time units such as seconds, minutes, or hours.