Optimising engineering team delivery using the Cycle Time metric
By: Dimitri Koubaroulis
Tags: Agile, Delivery, Cycle Time, Engineering

Delivery health is a key element of a healthy engineering team. At SafetyCulture we are not simply looking for delivery health. We aspire for world-class level excellence in how we deliver value to customers.

This is particularly important to me as an engineering manager accountable for product delivery. I need methods and tooling that make it easy to support multiple cross-functional teams building some of the most critical components of our flagship iAuditor product. I recently had the opportunity to experiment with exactly that. The experiment was successful and I hope my learnings are useful to you.

In a fast paced agile environment such as SafetyCulture the flow of a team’s work was identified as a key productivity indicator reflecting delivery health. In simple terms, you can think about flow as the average rate of getting things done as a team. Flow is the rhythm or pulse of the team’s delivery engine. For example, at SafetyCulture our product teams aim to deliver customer value every 3–5 days on average.

Flow is the rhythm or pulse of the team’s delivery engine

Optimising for flow is better than other agile measurements such as velocity based on story points as it works in the language of the customer (wall clock time). Other benefits include improved predictability, streamlined team operations, boosted team morale and the ability to be truly agile when process or behavioural change is needed. For a detailed analysis of the benefits of flow versus other delivery health metrics I highly recommend Daniel Vacanti’s book “Actionable Agile Metrics for Predictability: An Introduction”.

How do we measure “flow”?

At SafetyCulture our teams manage work using Scrum, Kanban and all variations of styles in-between. We needed a metric that was agnostic to the iteration style of the team.

The metric we chose to measure flow at SafetyCulture is the team’s cycle time. In simple terms, cycle time is the time between when someone starts working on a task and the time the task is done. Our goal is not to minimise the cycle time, rather it is to keep the cycle time stable within an agreed time range. The time range is defined by the team depending on the nature of the tasks undertaken. We found for most product teams in our environment a 3–5 days is a reasonable goal to aim for at this time.

cycle time is the time between when someone starts working on a task and the time the task is done

We wanted to be able to answer questions like “what was our team’s cycle time in the last 7 days?” and “how stable was our team’s cycle time over a time period?”. Additionally we wanted a way to quickly visualise the cycle time trend and be able to drill down to the supporting data to derive actionable insights at any time.

As we use JIRA for managing work, we first experimented with the built-in JIRA cycle time reports. Using JIRA’s built-in cycle time scatterplot went some way into answering the “what is our cycle time” question. However, we needed more powerful tooling to answer all our other questions above. We found that the “Actionable Agile” plugin for JIRA gave us most of what we needed. See some examples below for how we made the most of it.

Here is an example of one of our team’s cycle time trend over time. The different colours indicating different types of work items like stories, bugs and tasks.

A team’s cycle time trend over a year

At a glance we can see the average cycle time was 5.3 days and 64% of tasks were completed within the 5.3 days average. Productive conversations can be had immediately by looking at the graph around what it would take to have more work items completed within the desired cycle time. Or how we could break down work better so that some items that took a bit longer than our desired range could fit within it.

Productive conversations can be had immediately by looking at the graph

The trend on that graph is fairly stable except for some time periods which insightfully correspond to challenging times for that team such as losing key team members and on-boarding new ones.

Looking at such graphs in retrospect we can learn lessons about how to avoid similar spikes. Most importantly, looking at such graphs in real time helps identify spikes before they happen and take corrective action to optimise flow.

How do we optimise “flow”?

The first step to optimising flow is to measure and visualise it and spend some time with the team understanding it. If the cycle time is not stable the team will typically discuss how to make it stable. Once stable, if the cycle time is longer than what the team thinks is healthy, the team will discuss what needs to be done to bring it within the desired time range. I have found all of these very productive conversations that always yield positive corrective actions where required.

Here are a couple of examples from the many interesting findings:

In one situation, Android pull requests were taking up to 12 days to complete. This was identified by the team’s cycle time trending upwards. We asked some more Android developers to help with code reviews, cycle time was restored and our Android delivery cadence was healthy again.

In another example, one of our engineers was leaving stories in progress for two or three weeks at a time, waiting to deploy them to production until after all sub-tasks had been completed. We discussed ways to optimise for incremental delivery to production, they adjusted their way of breaking down work and had a very positive impact on team delivery shipping value every few days to production!

The result of corrective actions can be seen almost immediately, within a few days or weeks. Here is an example of another of our teams which optimised their cycle time from a spike of more than 20 days down to 5 days recently

Optimising flow over 4 weeks

The result of corrective actions can be seen almost immediately, within a few days or weeks

Wish list

One thing I wished we had with Actionable Agile is the ability to share a link to a filtered view of a team’s analytics. A built-in ability to email us an updated cycle time report for each team at regular intervals would be greatly welcome too!

Closing remarks

Tracking team delivery health by using the team’s cycle time to measure and optimise the flow of work has been rewarding for our product teams at SafetyCulture. Cycle time conversations are becoming more and more part of our team culture. Every team member can easily understand how their work contributes to the team’s delivery rhythm. Work is flowing better than ever before with less streams of work being blocked and more incremental delivery across the board.

As useful as they are, cycle time scatterplots and trends are only the beginning of our exploration into team delivery metrics. Stay tuned for more updates on this topic. Or even better, come work with us, we are hiring!