Lead time for change is the elapsed time between initiating a software change and deploying it to production. It reveals how quickly teams can deliver customer value and where delivery friction accumulates. section 3.4.3 section 10.1.1
Measure lead time broadly and break it down to expose recoverable waste:
- Start with the time from a developer picking up a story to production, then include planning time for requesting dependencies from other teams. section 3.4.3
- Distinguish lead time from deployment time: deployment time measures a starter-kit pipeline’s movement from the first Git push to running production. section 3.4.3
- Analyze build, test, and approval stages separately to identify bottlenecks and target improvements. section 10.1.2
- Account for dependency delays, planning overhead, meetings, and handoffs when mapping the complete path to production. section 3.2.1
Epetech’s pipeline analysis
Epetech reduced the time from code commit to production release by examining build, test, and approval delays. Teams used these breakdowns to locate bottlenecks, improve delivery speed, and support faster feature and fix releases. section 10.1.2
Practical measurement exercise
Map current software delivery processes, identify handoffs and bottlenecks, and write scripts using Jenkins, GitLab, or Jira APIs to collect lead-time data. Re-run the scripts after a controlled CI/CD rollout to compare results. section 10.3.3
Figure 3.4 A sample VSM for software delivery, mapping steps from planning to support and highlighting delays or bottlenecks. The times shown should account for all tasks or meetings, using averages for recurring items such as quarterly reviews.
Use the value-stream map to inspect the complete planning-to-support flow and locate delays beyond the deployment pipeline. section 3.2.1
