Numerous metrics are available for monitoring software development progress and generating reports that indicate the performance of your engineering team can be a time-consuming task, taking several hours or even days.
Through our own research and collaboration with industry experts like DORA, we suggest concentrating on cycle time, also referred to as a lead time for changes, which we consider the most crucial metric to monitor.
This measurement indicates the performance and efficiency of your teams and developers. In this piece, we will cover what cycle time entails, its significance, methods for calculating it, and actions to enhance it.
What is cycle time?
Cycle time in software development denotes the duration between an engineer’s first commit and code deployment, which some teams also refer to as lead time. This measurement indicates the time taken to finalize a specific development task. Cycle time serves as a valuable metric for deducing a development team’s process speed, productivity, and capability of delivering functional software within a defined time frame.
Leaders who measure cycle time gain insight into the speed of each team, the time taken to finish specific projects, and the overall performance of teams relative to each other and the organization. Moreover, optimizing cycle time enhances team culture and stimulates innovation and creativity in engineering teams.
However, cycle time is a lagging indicator, implying that it confirms ongoing patterns rather than measures productivity. As such, it can be utilized as a signal of underlying problems within a team.
Since cycle time reflects the speed of team performance, most teams aim to maintain low cycle times that enhance their efficiency. According to the Accelerate State of DevOps Report research, the top 25% of successful engineering teams achieve a cycle time of 1.8 days, while the industry-wide median cycle time is 3.4 days. On the other hand, the bottom 25% of teams have a cycle time of 6.2 days.
How to measure cycle time?
Measuring cycle time using Jira or other project management tools is a manual and time-consuming process, which requires reliable data hygiene to deliver accurate results. Unfortunately, most engineering leaders have insufficient visibility and understanding of their teams’ cycle time.
Typo provides instantaneous cycle time measurement for both your organization and each development team using your Git provider.
Our methodology divides cycle time into four phases:
- The coding time is calculated from the initial commit to the creation of a pull request or merge request.
- The pickup time is measured from the PR creation to the beginning of the review.
- Review time is calculated from the start of the review to when the code is merged, and
- Merge time is measured from when the code is merged to when it is released.
The subsequent phase involves analyzing the various aspects of your cycle time, including the organizational, team, iteration, and even branch levels. For instance, if an iteration has an average review time of 47 hours, you will need to identify the branches that are taking longer than usual and work with your team to address the reasons for the delay.
What causes high cycle time?
Although managers and leaders are aware of the significance of cycle time, they aren’t necessarily armed with the information necessary to understand why the cycle time of their team may be higher or lower than ideal. Leaders may make decisions that have a beneficial impact on developer satisfaction, productivity, and team performance by understanding the processes that make up cycle time and exploring its constituent parts.
Cycle time could increase as engineers wait for builds to finish and tests to pass before the PR is ready for review. When engineers must make modifications following each review and wait for a drawn-out and delayed CI/CD that extends the time to merge, the process becomes even more wasteful. This not only lengthens the cycle time but also causes contributors to feel frustrated.
Large PRs:
The time it takes to open a PR increases because large-sized PRs take longer to code and, as a result, stay closed for too long. For instance, the majority of teams aim for PR sizes to be under 300 changes, and as this limit rises, the time to open the PR lengthens. Even when huge PRs are opened, they are often not moved to the code review stage because most reviewers are reluctant to do so for the following two reasons:
A high PR indicates that the reviewer put a lot of effort into the review. To accommodate a significant code review, the reviewer must plan and significantly restructure their current schedule. It takes heavy and intense effort.
Huge PRs are notorious for their capacity to add a number of new bugs.
Lack of Documentation:
Code comments and other forms of documentation in the code are best practices that are regrettably frequently ignored. Reviewers and future collaborators can evaluate and work on code more quickly and effectively with the use of documentation, cutting down on pickup time and rework time. Coding standards assist authors in starting off with pull requests that are in better shape. They also assist reviewers in avoiding repeated back and forth on fundamental procedures and standards. When working on code that belongs to other teams, this documentation is very useful for cross-team or cross-functional collaboration. Various teams adhere to various coding patterns, and consistency is maintained by documentation.
Teams can greatly benefit from a readme that is relevant to a codebase and contains information about coding patterns, and supporting materials, such as how and where to add logs, coding standards, emit metrics, approval requirements, etc.
High CI/CD time:
Cycle time could increase as engineers wait for builds to finish and tests to pass before the PR is ready for code review. When engineers must make modifications following each review and wait for a drawn-out and delayed CI/CD that extends the time to merge, the process becomes even more wasteful. This not only lengthens the cycle time but also causes contributors to feel frustrated. Moreover, when the developers don’t adhere to coding standards before entering the CI/CD pipeline can increase cycle time and reduce code quality.
Developers' burnout
Engineers may struggle with numerous WIP PRs due to an unmanaged and heavy workload, in turn reporting lengthier coding and rework times. Reviewers are more likely to become overburdened by the sheer volume of review requests at the end of a sprint than by a steady stream of PRs. This limits reviewers’ own coding time as their coding skills start deteriorating and causes a large number of PRs to be merged without review, endangering the quality of the code.
The team experiences a high cycle time as reviewers struggle to finish their own code, the reviews, and the rework, and they suffer burnout.
Lack of sanity checks
When teams fail to perform simple sanity checks and debugging needs before creating PRs (such as linting, test code coverage, and initial debugging), it results in avoidable nitpicks during a code review (where the reviewer may be required to spend time pointing out formatting errors or test coverage thresholds that the author should have covered by default).
How optimizing cycle times helps engineering leaders?
So, now that you’re confidently tracking cycle time and all four phases, what can you do to make your engineering organization’s cycle time more consistent and efficient? How can you reap the benefits of good developer experience, efficiency, predictability, and keeping your business promises?
Benchmark your cycle time & identify problem areas:
Start measuring the cycle time and breakdown in four phases in real-time. Start comparing the benchmarks with the industry standards.
Once you’ve benchmarked your cycle time and all four phases, you’ll know which areas are causing bottlenecks and require attention. Then everyone in your organisation will be on the same page about how to effectively reduce cycle time.
Set team goals for each sprint to improve:
We recommend that you focus on one or two bottlenecks at a time—for example, PR size and review time—and design your improvement strategy around them.
Bring past performance data to your next retro to help align the team. Using engineering benchmarks, provide context into performance. Then, over the next 2-3 iterations, set goals to improve one tier.
We also recommend that you develop a cadence for tracking progress. You could, for example, repurpose an existing ceremony or make time specifically for goals.
Automate alerts using communication tools like Slack:
Build an alert system to reduce the cycle time by utilizing Slack to assist developers in navigating a growing PR queue.
These pieces of data enable the developer to make more informed decisions. They respond to questions such as: Do I have enough time for this review during my next small break, or should I queue it?
Adopt agile practices:
Many organizations are adopting agile methodologies. As they help in prioritizing continuous feedback, iterative development, and team collaboration. By adopting these practices, the team can leverage their coding skills and divide large programming tasks into small, manageable chunks. Hence, completing them in a shorter cycle to enable faster delivery times.
Conclusion
The most successful teams are those that have mastered the entire coding-to-deployment process and can consistently provide new value to customers.
Measuring your development workflow with typo’s Engineering Benchmarks and automating improvement with Team Goals and our Slack alerts will enable your team to build and ship features more quickly while increasing developer experience and quality.
