Introducing Cycle Time for ZenHub
Agile software development practices require you to track metrics as you improve your development processes. Without metrics and reports, it’s hard to decide on areas to improve, tackle challenges as you iterate on your workflow. In this article, we explain why cycle time, a true Kanban metric, is crucial to understand areas of improvement, optimize development, and make data-driven decisions.
At Adphorus, we’ve adopted the Kanban framework for our development teams. Our previous experience with Scrum posed a few issues that lent us some learnings:
- Agility: Planning sprints in a rapidly-changing digital marketing environment is highly unreliable. Issues become critical in case of major changes on clients side which does not always allow us to define a clear sprint scope. You need to be more agile, so to say, in order to meet the needs which brings us to the point below.
- Managing expectations: Our major travel clients are running countless Facebook marketing campaigns all the time. We are dedicated to providing the solutions and service they need to maximize the impact of their marketing efforts. However, this often translates to unplanned features or improvements with fixed release dates. Instead of adding on to long to-do lists, we prefer meeting these expectations as they arise.
- Continuous delivery: Even after two weeks of iterations, releases can become quite complex, touching a lot of different components of the application. We needed a leaner approach, a continuous flow of short release cycles.
As a result, we ended up transitioning to Kanban, which has given us much more flexibility in terms of planning and delivery. Its core principles definitely resonated with our team better, especially: Start with what you do now.
Our workflow was already visualized on a digital board in an issue tracker. We use GitHub for collaborating around code, and we wanted to have full transparency and ease-of-access for developers when it comes to project tracking as well. This is why we initially decided to migrate to ZenHub.
We faced one main challenge — managing the flow was quite hard without the proper metrics. ZenHub reports were limited to Scrum framework charts; such as Burndown and Velocity. As a Kanban team, cycle time was the most important metric we needed to be tracking. This is basically “time spent working on an issue”. In order to make incremental changes and improvements to our workflow (one of Kanban’s fundamental principles: Agree to pursue incremental, evolutionary change), we needed to identify bottlenecks and understand the impact they have on the overall system. Cycle time helps you address just that.
As there was no option to have this reported on ZenHub, we first subscribed to this ongoing issue and then decided to reach out for further support. We received an “it’s on our radar” response, with no further update. As a firm believer in the DIY principle (hey, we’re developers!), we decided to address the issue ourselves using ZenHub’s issue events API.
A scatter plot is the best way to visualize cycle time trend across many issues for deeper analysis. See JIRA Sofware Control Chart for how to read and understand cycle time, where we actually got our inspiration from.
So, what do I mean by deeper analysis?
1. Visibility & Retrospection
“You can’t optimise something you don’t measure.” Sounds simple, but it’s critical for any system. Teamwork, our development workflow is no exception. If we can’t measure our workflow and bottlenecks, or retroactively understand root-causes and take measures, how can we optimise?
Cycle time sets the context for questions like:
- Why did these particular issues take so long?
- Where did they spend most of the time?
- If it’s UAT, how can we optimise it?
- Should we maybe include our Customer Success team to verify issues as well?
- OK, we have now onboarded the CS team to look at issues. Did it help? By how much?
Let’s take a look at the Cycle Time chart below for our Product board. We can see that, on average, we spend 6 days to review pull requests. There are clearly outliers in this graph; for instance, one particular issue took almost 27 days to review! Surely, we can do better than that. By looking at the rolling average and standard deviation we can conclude that we’re pretty much consistent when it comes to code reviewing. But, we definitely need to introduce some optimisations here. Perhaps, we should do regular code review sessions because we know that long running issues force more WIP. So, instead of taking more issues from the backlog, we should focus more on reviewing existing issues and getting them out of the door.
2. Forecast & Estimation
As I mentioned before, sometimes you have to give hard deadlines. In fact, what does a soft deadline even mean? Deadlines are inherently hard and tight, and it’s a binary game. You either hit them or miss them. Though, most of the time, deadlines are not set with a team consensus. They’re rather given based on highly subjective and anecdotal guesstimates by a couple of individuals. They’re not backed by past data.
As a Travel Marketing Science company, we think that our internal processes should be empirical, employing primary evidence and following a scientific approach. This way, you can confidently give real, unbiased deadlines.
Let’s take a look the chart below for our Support board. — This board contains all of our customer-facing bugs which need to be resolved in a timely manner. As you can see, although we have outliers in this chart as well, we can confidently say that 75% of those bugs get resolved within a day. According to our Median (50%), this is actually 6 hours, but expressing it as such is like flipping a coin. In order to be on the safe side, we can confidently tell our customers that 1 day is our current SLA.
3. Transparency & Motivation
At Adphorus, we hold a weekly all-hands meetings where we review our company-wide metrics, including product pipeline, revenue targets, sales funnel, and ongoing tests. Since our Dev team sits at the core of all departmental updates, previously we did not have a way of sharing strictly development-related metrics. This posed a barrier in recognizing the work of our team and celebrating wins. Now that we track cycle time, we can transparently share our team’s performance. Ultimately, this serves as both a source of credibility and motivation for our entire team.
Today, we’re happy to announce that we have open-sourced the project we’ve built for ZenHub boards. Now, all Kanban teams using ZenHub can easily track and report on cycle time. (And, we strongly encourage you to do so.)
It’s a standalone Django project which only has a cycle time chart at the moment. We’re planning to improve it (adding issue filters and such) and add new charts such as cumulative flow diagrams in the future. Go ahead and check out the repo description for get it up and running and feel free to contribute to it in any way.
Happy flowing!
