Why we love metrics? Learning with Lead time
Important: The original text is available at http://blog.plataformatec.com.br/2016/02/why-we-love-metrics-learning-with-lead-time/
Every time I think about indicators and metrics I remember a phrase from H. James Harrington that says:
“Measurement is the first step that Leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t get it, you can’t control it. If you can’t control it, you can’t improve it.”
Just to clarify, as an agilist, I understand “control” as the ability of the team to handle and formulate tools that bring self-management to the environment, instead of a culture of command-control.
Since I started to work on software development, I have seen metrics from two different points of view:
- In the “dark side of the force” metrics could be applied as a tool too see the team as a number and the only reason to collect them is to charge people and create hazardous conflicts. Examples of this type of metrics are Unit Tests written, Individual Velocity, etc. (take a look at “How To Not Destroy your Agile Team with Metrics”).
- On the other side of the “force”, metrics could promote actions of continuous improvement and bring visibility to the team.
At Plataformatec, we use metrics to understand how we can make things better based on data, as an exercise of continuous improvement.
This blog post is the first of a series that I will share some metrics and charts that we have been collecting, and how we are using them in our projects.
Let’s talk about Lead time
Quoting Wikipedia, it is possible to define Lead Time as the latency between the initiation and execution of a process. For example, the Lead time between the placement of an order and delivery of a new car from a manufacturer may be anywhere from 2 weeks to 6 months. In industry, Lead time reduction is an important part of lean manufacturing.
In the software development context, we consider the Lead time as the number of days between the begin and the end of an issue (e.g., user story). One important definition to measure the Lead time is to establish the done criteria. In some teams, “done” could mean a user story released to production, but for others could be the code merged into the master branch.
Frequently, we interpret the Lead time graphics to answer questions like:
- How much time the team need to develop a new issue?
- Are the issues being concluded in the iteration time-box limit?
- Is anything (e.g., size, complexity, uncertainty) affecting the Lead time? Has data variability been increasing in the last weeks?
Let’s see a practical example. Imagine a situation that you as an Agile Coach are mentoring the team C3PO. What type of insight can you get from the graphic below?
Drawing the 75th percentile line (the green line) we can note that 75% percent of the issues that have flowed through the process took 20 days or less to complete.
Another line we might want to draw is the 95th percentile. Based on that, it’s possible to assume that a new issue has a 95% chance of be completed in 37 days or less.
So, what we deduce from this case?
If someone asks the team to estimate the time necessary to develop a new issue, a guess could be some number in a range of 20 to 37 days. Since we have a high amplitude, estimates will not be very reliable.
Investigating further, it’s possible to identify that after the first release something happened because the Lead time raises to a new standard. Probably, in recent releases the team handled differences in issue sizes, complexity or uncertainty.
Another interesting thing to look in the graphic are the outlier cases (Lead times that are distant from others). More often than not, those outliers were caused by circumstances that are outside of the team’s control, but the team could use them as a useful material for retrospectives and lessons learned meetings.
To conclude, I would like to share five tips on how to optimize Lead time:
- Mentoring the Product Owner to standardize issues (release value with simple solutions).
- Bring tools for the team that could help them in the process of decreasing complexity and removing technical or business uncertainty.
- Analyze the Lead time distribution frequently. In the beginning, high variability will be normal but after some time is important to define a standard.
- Communicate to project stakeholders any variation and implement actions to control Lead time growth.
- Use the outliers cases as an opportunity to learn and to improve your process.
What about you? What type of question are you answering from Lead time? Share with us your thoughts in the comments below!
P.S.: In the next blog post of this series I’ll talk about how to use throughput and global burnup charts to have visible and predictable projects.