How We Halved DevOps Deployment Lead Time

The Problem

A DevOps team at a large enterprise handled cloud infrastructure deployments. A small DevOps team, working across multiple projects, supported development teams who needed environments to build and test their applications.

The team ran Scrum. They had two-week sprints, daily standups, sprint planning, and retrospectives. They had a Scrum Master too. They tracked velocity, so they were basically following the framework.

Yet deployment requests took roughly two months on average. Development teams waited that long for an environment, so projects stalled. The DevOps team blamed external dependencies, including networking, security, and architecture validation.

In retrospectives, they discussed “improving communication with other teams” and “better planning.” Sprint after sprint, nothing changed.

For context on where this sits : the DORA framework classifies teams by lead time for changes. Elite teams measure it in hours. At that level, this team was firmly in the low-performer category.

The Performance Gap

I started with the numbers. The business had a clear constraint: the infrastructure deployment lead time had to drop below 30 days to keep the entire deployment phase within 60 days. The current state: roughly two months, about double the target.

That gap meant development teams sat idle for weeks. Projects missed milestones. Frustration built across the organization. The cost was real. Every delayed deployment pushed back feature releases and burned budget on waiting.

What Direct Observation Revealed

I did not attend their Scrum ceremonies. I traced actual deployment requests through the system. I followed one specific deployment, from request to completion.

The process had multiple steps involving several teams. The DevOps team controlled only a portion of the work. The real problems I observed were not about coordination or communication. They were specific failures at specific points.

Here is what I observed:

A team member lacked the access rights needed 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, requiring re-validation from the architecture team. Days lost.

Nobody documented where to find entry points for key infrastructure requests. The team spent days figuring it out each time.

Requests for access controls bounced between teams because neither side knew which ticket type to create or where to route it. Over a week lost on a single request.

A document template for a critical provisioning step was wrong. Even the second version was incorrect. Nobody knew the correct process.

Teams sometimes created the wrong resource type because the routing between cloud-based and legacy systems was unclear.

None of these problems surfaced in standups. None appeared on the visual board. The ceremonies captured “waiting on networking” as a blocker, but never revealed why.

Six Root Causes

I traced the deployment and found six root causes, none of them visible in a standup. They fell into four groups:

• Access and permissions. Key team members were missing the access rights they needed, and only one person could grant them, who was unavailable.
• A process nobody knew. A team was unaware of a recently introduced infrastructure process, and that gap caused rework.
• No documentation, unclear routing. Nobody had documented the entry points for key infrastructure requests, and several teams were unclear on how to route access control requests.
• Wrong templates and resources. The template for a critical provisioning step was wrong, and so was the second version. Unclear routing between cloud-based and legacy systems also led teams to create the wrong resource type.

Four groups, six root causes, all at the handoffs. That is where the time went.

Each cause was verified. There was no guessing, no assumptions from retrospective discussions. This is how root cause analysis works when you go where the work happens, rather than discussing it in a meeting room.

The Value Stream Map

The value stream told the story:

About half the lead time disappeared in a single queue. Requests sat for weeks because teams did not know which ticket to create or where to route it (for task assignment to another team).

The visual board showed “in progress” and “blocked.” It did not show that requests bounced between teams, sat in the wrong queues, or waited because someone used the wrong template. The framework made work visible at the team level. It could not see the handoffs between teams, where most of the time vanished.

The Interventions

Deployment checklist. The team created a checklist covering every request type, entry point, and routing decision. No more guessing about which ticket to create or which team to contact. Each step listed what to do and the entry point for each request.

Front-loaded requests. They established a rule: start long-lead-time provisioning requests (such as access controls and service accounts) at the very beginning of deployment, rather than mid-process. Starting these requests early meant they could be completed in parallel with other work, rather than extending the critical path.

Infrastructure-as-code pipeline. The team built a pipeline that could deploy resources identically across all environments. It is one pipeline, customizable per environment. This eliminated manual configuration errors and significantly reduced the “automate deployment” step.

Early handover meetings. They scheduled handover meetings with receiving teams before deployment completion, not after. This surfaced missing information while there was still time to act. Previously, handovers happened at the end, and missing service accounts or configuration issues caused delays of days.

Documentation. We documented the correct processes for provisioning requests, access control routing, and key infrastructure entry points. Simple, but it did not exist before.

The Results

The deployment I traced: under 30 days. Down from about two months.

The team continued running Scrum. The ceremonies did not cause the problem, and stopping them was not the solution. But the improvement came from outside the framework: mapping the actual flow across teams, observing specific failures at specific points, identifying root causes through direct observation, implementing targeted fixes, and empowering the team.

Why Scrum Did Not Surface This

The retrospectives had discussed “communication with other teams” for months. Direct observation revealed that the problem was not communication. It was: missing documentation, unclear routing, wrong templates, and sequential requests that could run in parallel. Those are solvable problems using a structured problem-solving approach. “Better communication” is not.

Scrum makes team-level work visible. It does well at that. But when the waste hides in the handoffs between multiple teams, no standup or retrospective will find it. You have to trace the actual work, end to end, through the system. That is what value stream mapping does. And that is what Lean Tech adds to teams that have already adopted Agile.

I have seen this play out in every Agile team I have coached. The ceremonies run well, but the delivery still suffers. The system-level problems sit outside the team’s field of vision. I wrote about this dynamic here: The ‘Top Priority’ Problem: Why Engineering Teams Struggle With Delivery.

How This Connects to DORA Metrics

This case study attacked lead time for changes directly. Roughly halving the lead time moved the team from a low performer to a medium performer on DORA benchmarks.

The interventions also created conditions for the other three metrics. Deployment frequency can increase when infrastructure provisioning no longer bottlenecks the pipeline. Change failure rate dropped because the infrastructure-as-code pipeline eliminated manual configuration errors. We had the same code, the same result, and the same across every environment. Mean time to recovery improved because documented processes and clear routing mean faster resolution when issues arise.

Lessons Learned

Start deployment activities earlier. Request access controls and provisioning dependencies at the beginning, not when you need them. Long-lead-time dependencies should start first.

Document the handoffs. The work inside each team was reasonably efficient. The waste hid in the handoffs: wrong tickets, wrong queues, wrong templates. Document these explicitly.

Trace real work, not process maps. The official process showed a handful of steps. Reality showed dozens of failure points within those steps. You only find these by following actual requests through the system.

Checklists beat training. The teams knew their jobs. They failed at the boundaries because nobody documented what to do at each handoff. A checklist solved in days what “better communication” could not solve in months.

More than 50% lead time reduction. We had the same team, technology, and organizational structure. What changed was visibility into the actual flow and structured problem-solving aimed at specific failures.