The impact of high cycle time
Risk to 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.Â
Why should you be wary of very low cycle time?
Though a cursory glance of 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 causes 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.