Half Your Lead Time Hides Between Teams
A diagnosis, a countermeasure, and one real case. Three months of system work, and the part that won't hold on its own.
Your team ships faster than ever. AI writes a real share of the code now, velocity is stable, every ceremony runs on schedule. Delivery to the client is still slow.
I’ve been in that situation with many engineering teams. Here is the pattern I see, and what works.
The framework you are using is not the problem. Neither is the tooling. Your symptom is the gap: the teams look fine, the delivery does not. Faster code does not reach the slow part because the slow part lives between teams, in places no standups or ceremonies reveal.
Where the time went
The DevOps team ran Scrum. Two-week sprints, daily standups, sprint planning, retrospectives, all of it. They tracked velocity. By every internal habit, they were doing it well.
But a deployment was never this team’s alone. The request crossed four or five teams before any developer could begin.
The business wanted environments in thirty days. Their infrastructure deployments took roughly two months. Development teams waited that long for an environment to build on. Projects stalled. The DevOps team blamed external dependencies. Networking, security, architecture validation, the usual suspects. Retrospectives produced action items about improving communication with other teams and better planning. It was the same items, sprint after sprint, and nothing moved.
I followed one deployment request from the moment it was submitted until the environment was ready for use. The official process had a handful of steps. The reality I saw had dozens of failure points inside those steps.
A team member needed access rights to proceed. The only person who could grant them was unavailable. Days lost. A team unfamiliar with a recently introduced process inadvertently removed a resource. Re-validation from architecture. More days lost. A request for access controls bounced between two teams because neither knew which ticket to create or where to route it. Over a week, on a single request. A document template for a critical provisioning step was wrong. The replacement template was wrong too. Nobody knew the correct process.
None of these problems appeared in standups. None showed up on the visual board. The ceremonies captured “waiting on networking” as a blocker, but never revealed why.
Then I mapped that value stream end to end. The map showed something the team had never seen on a single sheet.
About half the lead time disappeared in one queue.
That queue was the access control and network provisioning step. Requests sat there for weeks. Nobody was working on them. The team had assumed the time was spread across the whole flow. It was concentrated in one place.
The value stream map was the moment everything shifted. Up to that point, the conversation had been about effort and commitment, about who wasn’t talking to whom. Once the map appeared on the Miro board, the conversation became about routing, templates, and handoffs. These are tangible and fixable things. Every department head who opened the map asked the same question. Why is that queue so long? That was the start of the change.
Why “improve communication” doesn’t work
The standard advice for a team with long deployment lead time is always the same. Communicate better. Plan earlier. Add a Scrum of Scrums. Maybe a coordination ceremony.
This advice fails for one reason. It treats coordination as a willingness problem. It isn’t.
People want to coordinate. They just don’t know which ticket to create, where to route it, which template to use, or who has the access they need. “Better communication” between teams who don’t share a vocabulary, a routing convention, or a template library is two people talking past each other more often.
The deeper problem is in the workflow that crosses four or five teams, where each crossing is a chance for something to bounce, sit, or get re-done. Scrum makes one team’s work visible. It cannot see the seams between teams.
Across engagements, the root causes consistently fall into four groups.
Access and permissions stall the flow. The people who can grant the access needed to move forward are a bottleneck of one. When they are unavailable, the work waits.
A process exists that not everyone knows. Something changed, and not every team got the memo. Teams act on outdated assumptions and break things that need to be rebuilt.
The handoffs are not documented. Entry points for cross-team requests live in someone’s head. Routing decisions are tribal knowledge. New people, or people new to that boundary, lose days figuring out what should take minutes.
Templates and resource definitions are wrong or unclear. The team trying to do the right thing fills in the wrong template, or creates the wrong resource type, because the boundary between systems was never made explicit.
None of these are team problems. They are system gaps that produce team problems. Add up four small structural holes at four different handoffs. You get a team whose two-month lead time is invisible to every ceremony it runs.
Rebuild the handoffs, not the team
The team I traced made five moves. Together they cut the lead time by more than half.
Mapped the value stream. Before anything else, the team needed to see what they couldn’t see from inside a sprint. The map showed exactly where the time went. The department heads stopped arguing once they could point at a queue. The map became the team’s first piece of shared truth.
Documented the handoffs. Every cross-team boundary got a written description. Which ticket type goes where, which template applies, who owns the routing decision. Tribal knowledge became standard work. New people stopped losing days at boundaries.
Front-loaded the long lead-time requests. The team established a rule. Anything with a known long wait time, access controls, service accounts, or security validation, gets requested at the start of the deployment, not when it’s needed. Those requests now run in parallel with the rest of the work instead of extending the critical path.
Built an infrastructure-as-code pipeline. One pipeline, customized per environment. The team stopped setting them up by hand. The errors that used to eat days disappeared, because the configuration was now code, reviewed and reproducible.
Moved the handovers earlier. Handovers used to happen at the end of deployment, when the receiving team discovered what was missing. The team moved them before completion, so missing access rights or unclear configurations surfaced while there was still time to act.
None of these required a new tool. None required a reorganization. The team kept running Scrum. What changed was the work between the teams, which had never been anyone’s job to look at.
Three months later
Back to the team we started with. Three months after the interventions were in place, the deployment I had traced was tracking under thirty days. Down from roughly two months. More than halved.
They were inside the target the business had set. Development teams stopped waiting for environments to start their projects. The constraint that had been the loudest complaint across the organization quieted down.
One thing didn’t come for free, and it’s the part most case studies leave out.
The gain was real. Holding the gain is harder. The team that built the checklists, the pipeline, the handover rhythm, and the documentation knows the system because they built it. The next person who joins doesn’t. The team across the wall who handles access controls knows the new routing convention. The next person on that team doesn’t. Onboarding into the new way of working isn’t standard yet. Turnover, even ordinary turnover, threatens what’s been built.
None of this is a failure of the intervention. It’s the next problem the system surfaces, made visible only because the first one was solved. A team that delivers in two months can’t even see this problem. A team that delivers in under thirty days has to.
The lead time number moved. The capability to keep it there is still being built.
The pattern
Engineering teams don’t have a velocity problem. They have a system that produces a lead-time problem, and most of it lives between the teams, not inside them.
Sprint dashboards make team-level work visible. They show what one team is doing. They cannot show what happens when work crosses a boundary, sits in someone else’s queue, bounces back because of a wrong template, or waits for an access right that one person can grant.
The fastest way to find where delivery actually breaks is not to optimize what you can see. It’s to trace one real request, end to end, through every team it touches. Map the wait time, not just the work time. The numbers on that map have started more conversations in my engagements than any retrospective ever has.
Map the flow first. The speed follows.
If you suspect your lead time hides between teams too, start with the Delivery Scorecard. Two minutes, ten questions, it points at the queue. And when AI tooling is part of the picture, I run a half-day working session with leadership teams on exactly this. Reply to this email and I'll send you the outline.