Lead time to change — the time between when a task is started and when the resulting code is in production — is one of the fundamental indicators of team health. When the time to get work to producion is high, it indicates productivity challenges on a software engineering team. By understanding and addressing the common culprits, teams can streamline their processes and deliver faster, higher-quality results.
Multitasking and context switching
Multitasking — and the context switching it requires — is one of the most significant factors contributing to high lead time to change. When developers have to juggle multiple tasks simultaneously, their efficiency drops due to the mental effort required to switch between different contexts.
WIP limits help teams focus on completing tasks rather than starting new ones. By restricting the number of tasks in progress at any given time, teams can concentrate their efforts on finishing current work, reducing the time spent on context switching. To keep work flowing, a safe WIP limit is usually smaller than the team’s size, reserving some of the team’s capacity for code reviews, vacations, and unplanned work. You never, ever want your team to be at 100% utilization: it’s well established that systems with little slack collapse under pressure.
Managing unplanned work
Implementing WIP limits implicitly makes it harder for the team to take on unplanned work, but it won’t reduce the demand for unplanned work — interruptions like incidents, leadership requests, customer needs, etc. Just like you need to limit the number of planned work items in progress, you need to have a limit to the amount of unplanned work you take on — and be honest about your ability to meet earlier commitments.
This starts with making unplanned work visible, for example by using a separate “swimlane” in your issue tracker. If you’re a manager, you must enforce the notion that the team can only do so much at once, and be prepared to enumerate the consequences — unfinished work, low quality work, untested work — of violating that standard.
Feedback loops
Feedback loops help a team quickly identify and address issues. They enable teams to catch problems early and make necessary adjustments without significant delays. Two tactics can dramatically increase the speed of your feedback loops: working “right to left,” and breaking work down into smaller tasks.
In a right-to-left workflow, teams focus on moving tasks toward completion rather than starting new ones, ensuring that work already in progress gets the attention it needs. When a team works this way, a team member looking for a new task will look first at the work that is closest to completion. Can they provide a code review? Can they help a fellow developer through a thorny problem, or otherwise unblock the team’s work?
Smaller tasks also implicitly result in faster feedback loops. It is easier to review a 50-line pull request than one that’s 500 lines. It’s easier to test a small change, and less risky to deploy it. If you run into tasks that team members expect to take more than a day or two, it’s a clear sign that you need to rethink: larger tasks are more susceptible to interruption and more likely to cause quality issues.
Team communication
A team that communicates well is more likely to share and address issues as they arise. Clarity on priorities within the team keeps the team focused on the right things.
Simple steps can help facilitate that communication — not every team needs a daily standup, but every team needs a way to make visible the work that’s happening, its status, and whether anything is putting that work at risk. Good issue tracker “hygiene” pays dividends in the asynchronous clarity it provides.
Teams also need to be able to communicate outside of scheduled meetings. When most people were in person, this was easier, but now a tool like Slack is essential. Encourage your team to have online conversations in “public” so everyone can access the same context.
Teams also need a regular opportunity to reflect on what’s working and what’s not. Retrospectives can play this role, but purely qualitative retrospectives can get old quickly, especially if no improvements are ever made. Consider retrospectives that include actual data about the team’s speed and quality of delivery — that data will spur continuous improvement conversations and give you a way to measure your progress toward those improvements.
Bottlenecks
Bottlenecks can occur at various stages of the development process, often due to manual testing, inefficient deployment processes, or the need for external approvals. When work sits idle, lead time to change and flow efficiency suffer.
As described above, a WIP limit can help prevent bottlenecks arising in human-driven processes like code review.
However, not all processes should be human-driven. Modern software engineering organizations have broadly embraced the need for automated testing, integration, and deployment of new code. When these tasks aren’t automated, work that is “ready” to be shipped sits still for days (or sometimes weeks) while a release is prepared and tested. Ideally, you want to be shipping work as soon as it’s ready.
The problem worsens when people stack up big changes rather than smaller ones, knowing they have a brief window to get their code into the world. As mentioned above, small tasks will flow more smoothly through the development process than large ones. Automating manual processes eliminates the bottlenecks that discourage smaller changes.
Introducing continuous integration and continuous deployment eliminates the need for a human to run the test and deploy process — in the best case, a code change can make it to production without human intervention within an hour or so of being ready to merge.
Summary
Lead time to change is one of a handful of key metrics for understanding whether your software engineering organization is performing at its best. When lead time to change is low, work flows through the system more smoothly and predictably. If you feel like there’s room for your org to be more productive, this metric could be a good place to start your inquiry.
Swarmia’s software engineering benchmarks focus on just a handful of metrics — including lead time to change — that help you understand how effectively you’re operating. Focusing first on these key metrics will help you identify areas of maximum impact when it comes to improving engineering effectiveness.
