Now there were some terrible seeds on the planet … A baobab is something you will never, never be able to get rid of if you attend to it too late. It spreads over the entire planet. It bores clear through it with its roots. And if the planet is too small, and the baobabs are too many, they split it in pieces . . .
— The Little Prince
Timing Matters. Time Matters, too.
The art of management is to act at the right moment. Good leaders allow team members to be autonomous when things are going in the right direction. In the same time, they are swift in fixing up issues when it was a minor problem, thus avert a crisis later on in time. Knowing the right time act is not easy. This ability used to come from years of experience through trials and errors. With modern source control tools (e.g. GitHub and GitLab) and agile process, analytic tools can be created to alert leaders when actions are required. In this article we will explain the concept of Cycle Time — the most important metric that tell you whether there are issues to be addressed.
Life of a Pull Requests
Cycle time is a metric obtainable if you team manages your source code repository through pull requests (GitHub) or merge requests (GitLab equivalent). Cycle Time measures the lifetime of a pull request. To use cycle time, we must first understand the life of a pull request.
Pull requests represents a task of implementing a feature or a bug fix. A pull request is opened when the developers (authors) starts working on the task. Authors will add code changes to the pull request until the total code changes meets the requirements. Then they announce it ready for review and wait for other developers (reviewers) to review the code changes. Reviewers, during review, may approve the pull request straight way or suggest modification. After the pull request is approved, the author or the reviewer may merge code changes into the main repository.
What is Cycle Time?
Cycle Time of a pull request is the time between the first commit and the pull request is merged. It is the sum of the following for sub-components:
- Development Time: Time took for the author to understand requirement and produce the first working implementation. Long development time could indicate planning or expertise issues.
- Response Time: Time took for a reviewer to start looking at the code change. Long response time could highlight teamwork or knowledge silo problems.
- Review Time: Time took for the pull request to be approved. This could involve multiple back-and-forth between the author and the reviewer. Long review time might uncover process and expertise deficiency.
- Integration Time: Time took for the code change to be integrated after being approved. Long integration time could surface the organisation’s problem with prioritisation and external dependency.
Why Does Cycle Time Matter?
Like canaries were used in coal mines to detect the presence of carbon monoxide, Cycle Time is used to detect processes inefficiencies so manager can mitigate them before they become systemic. As a rule of thumb, good engineering teams often have Cycle Time under 48 hours since any severed problem mentioned above would drag the Cycle Time beyond 48 hours. This makes Cycle Time the catch all metric for potential issue that needs addressing.
The Logilica Insights watches over your repository, distills management related information from noises, aggregates the key insights into easy-to-understand-metrics (such as Cycle Time), and continuously updates dashboards that can be drilled down into the related aspects to making evidence-based decisions. Logilica Insights is structured around work streams, which groups activity objectives together.
The “Cycle Time” work stream give you near real-time insight of how the project is going. It gathers all relevant information in one place and compares them with historical values.
The colouring give you a sense of health. By checking the “Cycle Time” work stream regularly you can be alarmed the team might need your help. All done in seconds. Here is what you might want to focus on:
- Look at the trend, if it is increasing. Keep an eye on it and allow team to self-adjust and improve.
- Examine the breakdown of sub components to further identify potential issues.
- Drilldown to the outliers to see if the problem is transient or not.
If you want a single number to tell you how well the team is functioning, nothing compares to cycle time. Cycle Time is a good tool in the belt of engineering manager. Long Cycle Time indicates now is the time you to intervene. A modern git analytical tool like Logilica Insights can help leader to act in a timely manner to avoid later engineering disasters.