I followed one deployment request from the moment it was submitted until the environment was ready. The official process had a handful of steps. What I watched had dozens of places it could stall.
The team ran Scrum well. Two-week sprints, standups, retrospectives, and stable velocity. None of it could see where the request was actually sitting.
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. The slow part lives between teams, in places no standups or ceremonies reveal.
Where the time went
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.
Here is what the request actually ran into.
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 put the whole thing on one sheet. The map showed something the team had never seen.
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.
There is one thing I need to say about this team, because it became a problem once the lead time dropped.
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
Scrum showed this team everything that happened inside the sprint. It showed them nothing about the weeks a request spent waiting in someone else’s queue. That is where half the lead time was.
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.
The lead time is under thirty days today. Whether it stays there depends on how well the next new hire on the access team learns the routing. Nodody has written that down yet. If you want to try this, pick one real request and follow it across every team it touches. Write down how long it waits at each step, not only how long someone works on it.