When someone mentions lead times in software delivery, it's often unclear whether they mean the definition of lead times from Lean Software Development, the one from DevOps, or something else entirely. In this post, I look at why there are so many definitions of lead time and how you can put them to use. Lead time definitions The is the time between a developer committing code into version control and someone deploying that change to the production environment. This definition covers a smaller part of the software delivery process than the Lean definition. DevOps definition of lead time for changes Mary and Tom Poppendieck created Lean Software Development based on the lean manufacturing movement, and they measured lead time from when you discover a requirement to when someone fulfills that requirement. The Lean movement, based on the Toyota Production System, defines lead time as the time between a customer placing an order and receiving their car. Lead time is a customer measurement All these lead times represent a customer measurement. But they differ because the customer is different. Toyota measured the system from the perspective of a car buyer The Poppendiecks measured the software development system as the users see it DevOps measures the deployment pipeline from the perspective of the developer as the customer The key to successful lead time measurement is representing how the customer views the elapsed time. Cycle times When you measure a part of the system, you're collecting a . In the car industry, it's useful to track how long it takes for a car to move along the production line. In software delivery, it's common to collect the cycle time from when a work item starts to when it's closed. This indicates the performance of software delivery without the varying wait times that can occur before work begins. cycle time As the coffee shop example shows, your customer doesn't care about cycle times. While you can use cycle times to measure different parts of the system to identify bottlenecks constraining the flow of work, you should always keep the complete system in mind. In software delivery, it's common to find a large proportion of elapsed time is due to work waiting in a queue. For example, a requirement that would take a few days to deliver might sit in a backlog for months, or a pull request may wait for approval for hours or even days. You can identify these delays by subdividing your system and measuring each part. Lead times measure the real output of a system, but cycle times help you find the system's constraint. All measurements are useful Lead time is valuable because it represents the customer's perception. Identifying your customer and tracking lead times as they see them ensures any improvements you make impact their experience. If you make an improvement that doesn't reduce the lead time, you've optimized the wrong part of your system. In some cases, reducing the time for the wrong part of the system can even increase the overall lead time if it adds additional stress at the constraint. The Theory of Constraints, created by Eli Goldratt, tells us there's always at least one constraint in a system. Optimizing anywhere other than the constraint will fail to improve the performance of the whole system. Cycle times and other part-system timers help you work out where optimization is likely to reduce the overall lead time, so you can use cycle times and lead times together to assess the improvement. Common software delivery constraints There are some common constraints in software delivery: Working in large batches Pull request approval queues Having too many branches, or branches that exist for too long Manual testing Policy constraints, such as unnecessary approvals Hand-offs between functional silos (such as development, testing, and operations) Some of these constraints are reflected in the Continuous Delivery commit cycle, which has the following recommended timings: Commits every 15 minutes Initial build and test feedback in 5 minutes Any failures fixed or the change reverted after 10 minutes Conclusion The different definitions of lead time reflect various customer perceptions of parts of the same process. You can use as many measurements of lead and cycle times as you need to find and resolve constraints in your system. You can track the lead times over the long term and use cycle times temporarily as part of a specific improvement exercise. When you improve or optimize, lead time can help you understand if you're positively impacting the whole system. Happy deployments! Also Published Here

From Maturity to Capability: The Evolution of DevOps Models

The Relationship between DevOps and Platform Engineering

Too Long; Didn't Read

Make resilience your competitive advantage

What is Lead Time and Why Does it Have So Many Definitions?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

7 Common Misconceptions about DevOps Metrics

104 Stories To Learn About Continuous Integration

139 Stories To Learn About Cicd

15 of the Best Continuous Delivery Tools

Improving the Working Environment for Developers - In 3 Stages Only

7 Common Misconceptions about DevOps Metrics

104 Stories To Learn About Continuous Integration

139 Stories To Learn About Cicd

15 of the Best Continuous Delivery Tools

Improving the Working Environment for Developers - In 3 Stages Only

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps