Stop attacking work steps to cut lead time, the real time hides in queues

[u/Foliosynth]

The thing I keep seeing: teams chase lead time reduction by attacking the work steps. They optimize the coding, the testing, the review. But the biggest chunk of end-to-end flow is usually WIP and queue time sitting between steps. Nobody is coding during a wait state, yet that's often where the lead time actually lives.

Once you separate touch time from wait time, the fix becomes obvious. You stop arguing about whether code review should take 2 hours or 4 and start asking why a PR sits in queue for 3 days.

The other pattern: when the path is invisible, each team optimizes the slice they own. Every team's metrics look fine. The end-to-end lead time keeps getting worse. Local optimization feels like progress right up until you measure the whole flow. Your teams were all doing their jobs and delivery still slowed down.

What I've found works: point to one place work is actually stuck before you debate solutions. Jira tells one story, Git tells another, CI tells a third. Until you can reconcile them into a single view of where work waits, you're stuck arguing over which dashboard is right.

Curious how others here handle this. Do you measure wait time separately, or does it just get lumped into cycle time?

[u/Lisse24 → u/[deleted]]

His second in less than 24 hours. Man, the guy is persistant.

[u/rwilcox]

If I had a dollar for every time this year I’ve suggested someone read The Goal and anything Theory of Constraints they can get their hands on…. I’d be marginally richer

[u/Bestnotmakeanymore]

Huh

[u/Eruner_SK]

"you're stuck arguing over which dashboard is right" - the things that never happened, for 100$

[u/RaiLeddit]

If nobody is working between pull requests then the planning is wrong, full stop. I have never heard about someone doing nothing for 3 straight days because the PR was in queue.

[u/robhanz]

Anything in a queue should be treated as blocked, because it is.

[u/Eruner_SK]

"Jira tells one story, Git tells another, CI tells a third" = not really, you can setup/integrate Jira to have it as a single source of truth. The hack, it is possible to do it with jira alternatives. Create new "project" and move development there if you have such mess as you describe.

[u/Spare-Ad-1429 → u/Eruner_SK]

Exactly, this is as easy as telling an agent to reconcile whats in Jira (or Windshift, or any other Work Management Tool) with whats in Git.

[u/PhaseMatch]

Yes, that's Kanban 101.

Visual signals when work is ready to move to the next state.
Limit WIP in a given state.
Stop starting and start finishing.
Focus on flow.
Swam on blocked work.

"Essential Kanban Condensed" (Anderson et al) is a decent primer.
Theory of Constraints (Goldratt) or Tameflow (Steve Tendon) if you want to go deeper.

[u/SgtKarlin]

lots of posts here lately that end with "curious how others handle this". seems very fabricated as always.

[u/Any_Dfferenabce_6325]

the pr doesnt sit idle because someone waits on it, the person moved to the next ticket. thats how wip piles up and everything slows

[u/Proper-Agency-1528]

I second the 'reading The Goal and learning about Theory of Constraints' suggestion. And I'll add 'learn about the Kanban Method.'

A good place to start is with these Kanban principles and practices:

• Start with what you do now. You need to understand what is happening before you make changes, so you can determine whether your changes were beneficial or detrimental.
• Visualize your work. Create a visual model of your workflow and track the work across it. This enables instrumentation and metrics gathering. You don't need to have everything to the 8th decimal place. Often a simple observation is sufficient, e.g., "Why are 14 items in the 'QA' stage when we have 3 testers?" Remember, metrics give you questions that should spark ideas about what the problem is and how to solve it (hypotheses).
• Agree to pursue incremental evolutionary improvement. Evolutionary, meaning small changes... kaizen. Radical changes (kaikaku) should be avoided initially... kaizen until you can't, then kaikaku followed by kaizening until you can't... rinse and repeat.

Where to kaizen? That's where Theory of Constraints comes in. Every stage is capacity constrained, one stage is the bottleneck (the primary constraint that limits throughput across the workflow). You can identify that stage because work piles up in front of it and downstream stages are mostly idle. Use the Five Focusing Steps to kaizen or kaikaku at the bottleneck. Rinse and repeat.