Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇
Last week we explored software delivery metrics and how they predict overall engineering efficiency.
This week I follow up, with a broader scope, to discuss my favorite metric of all: Cycle Time.
📈 The Rise of Engineering Analytics
Over the last couple of years, several analytics tools rose to support a data-driven approach to Software Engineering.
You may (or may not) know a few of them: LinearB, Code Climate, Waydev, Flow.
They connect to your code hosting (e.g. Github) and automatically create measures based on commits, PRs, and releases.
Among these measures, I would argue that Cycle Time is the most significant one. To the point that if you had to focus on just one KPI for your dev process, it should probably be it.
Let's see what it's all about.
🍀 The Four Stages, and Lead Time
Depending on who you ask, dev life cycle has four to eight steps, and even Google seems to be a bit confused about it.
For the sake of this topic, let's keep it simple and consider four of them:
📋 Design — requirements and analysis are performed. Work is split into batches and properly planned.
🔨 Coding — code is written by devs, together with tests and further docs.
🔍 Review — code is reviewed, in multiple ways: CI pipeline performs tests, peers perform code review, QA possibly steps in.
🚚 Deploy — code is merged on the production trunk and released.
The time that goes from Design to Deploy is called Lead Time.
Agile's main teaching, with respect to Waterfall, is to keep Lead Time short.
Lead Time, however, is an all-in-one metric — it includes everything. It's not easily actionable, because it's the sum of very different steps.
➰ Cycle Time
As seen last week, a great strategy to keep Lead Time short is to focus on the Review and Deploy steps.
These are predictable activities that can be made efficient via Continuous Delivery practices. Run automated tests. Deploy in 10 minutes. Recover fast.
Lead Time covers all the four steps, and delivery metrics the last two. Cycle Time hits the sweet spot by covering Coding, Review and Deploy.
Cycle Time is defined as the time that goes from the first commit to the release in production.
The intuition behind it is that by working in small batches and making delivery efficient, Coding time should become predictable too. This way, Cycle Time becomes a reliable measure that can be analyzed and optimized over time.
But why is Cycle Time such a good metric?
⚖️ The Virtues of Cycle Time
Cycle Time possesses all the hallmarks of great KPIs:
It's objective: it doesn't need context to be interpreted, you know exactly what it means.
It's easy to understand: it can be easily discussed and explained to management, as it works like the engineering equivalent of sales cycle and product funnel metrics.
It stays relevant as you scale: it doesn't depend on the size of the team.
It's actionable: it shouldn't fluctuate much. Significant increases usually point to specific problems that can be identified and resolved.
🔍 How to Measure Cycle Time
If you want to track Cycle Time in your team, there are several tools that allow you to do so, also with a breakdown of the various steps. This is a partial list:
They integrate with your code hosting to monitor commits, PRs and releases, and compute numbers automatically.
In alternative, you can track it on various project management tools like Jira, or Clubhouse (not that Clubhouse!) — but in this case you only get the aggregate number, without the chance of drilling down into the single steps.
📚 Resources
A lot of resources this week! It's a hot topic and there is no lack of quality content about it, as more and more people get interested in starting a metrics program in their team.
Here are a couple of great primers, provided by tools from the list above:
📃 Metrics Runbook for Dev Teams — by LinearB, takes on key concepts like Cycle Time, Investment Profile and Rework Ratio.
📃 The Data-Driven Engineering Leaders' Playbook — by Waydev, explains how to use metrics to improve Standups, 1:1s and other engineering processes.
For a wider perspective, you can also check these:
📺 Translating Engineering to Executives — in this great talk, Ori Keren discusses how to build a shared vocabulary between Engineering and Management.
📖 Lean Software Development: An Agile Toolkit — this seminal work by Mary and Tom Poppendieck introduced many key concepts for modern software development, including Cycle Time.
📖 Accelerate: The Science of Lean Software and DevOps — if you missed it from last week, here it is again! Especially recommended if you want to dive into delivery metrics.
And that's it for this week! Do you have any experience working with Cycle Time and other engineering metrics? Let me know in the comments or via email!
Hey, I am Luca 👋 thank you for reading this far!
Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.
Subscribe below to receive a new essay every Friday and put your own growth on autopilot!
Thanks a lot for this, @Luca! Do you have any preference or recommendation for the ideal frequency or time periods to be measuring cycle time across, to best help the team? Would appreciate your thoughts. Thanks!