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 working on software development, I have seen metrics from two different points of view:

1. In the “dark side of the force”, metrics could be applied as a tool to see the team as a number and the only reason to collect them is to demand answers from 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”).
2. In 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 where 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 the industrial goods sector, Lead time reduction is an important part of lean manufacturing.

In the software development context, we consider Lead time as the number of days between the beginning and the end of an issue (e.g., user story). One important definition to measure 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 charts to answer questions like:

• How long the team needs to develop a new issue?
• Are the issues being concluded in the iteration time-box limit?
• Is anything (e.g., size, complexity, uncertainty) affecting 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 chart 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 being completed in 37 days or less.

So, what do 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 analyze on the chart are the outlier cases (Lead times that are distant from others). More often than not, those outliers were caused by circumstances that are beyond team control, but the team could use them as useful material for retrospectives and lessons learned meetings.

To conclude, I would like to share five tips on how to optimize Lead time:

1. Mentoring the Product Owner to standardize issues (release value with simple solutions).
2. Bring tools to the team that could help them in the process of decreasing complexity and removing technical or business uncertainty.
3. Analyze the Lead time distribution frequently. At the beginning, high variability will be normal but, after some time, it is important to define a standard.
4. Communicate to project stakeholders any variation and implement actions to control Lead time growth.
5. Use the outlier cases as an opportunity to learn and to improve your process.

What about you? What type of question are you answering based on 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