Why Does My Team Ship So Slowly?

We have a team of developers and a full backlog, and a simple change still takes weeks to reach users. Everyone's busy all day. Should we hire more developers?

Not yet. Most of that time is waiting, not work. The code takes hours, and the queues around it take days.

Everyone being busy all day is the clue. When a busy team ships slowly, the work sits between the busy parts. It waits for a review nobody has time for, or a release nobody has run.

So I'd start with a clock, not a hire. Measure where a change waits, find the bottleneck, then fix it.

Code Takes Hours, Queues Take Days

Follow one task from the board to users and time every stage. That's cycle time.

A task gets picked up, coded, opened as a pull request, reviewed, merged, tested, deployed and released. Most of those stages are handoffs. Each one waits for a person or a machine to be free, and the work itself is often the shortest part.

That's why working harder doesn't help. The developer is already done, and the task is sitting in a queue.

The clock starts when someone picks up the task and stops when it's live for users, not at merge. I count done as released to real users.

No new tool is needed: the timestamps already exist. The board shows when a task moved to in progress and to done. The pull request shows when it opened, got its first review and merged, and the deploy log when it went live.

Cycle time also replaces velocity. Story points measure what the team estimated, and in small teams velocity tracking turns into theater fast.

The clock shows where the time goes. What to do with it comes from a factory.

The Slowest Step Sets the Pace

Delivery is a line: a task moves from station to station, from the board through review and testing to release. Eliyahu Goldratt's The Goal, a novel about a factory, taught me years ago to look for the station that caps the flow. It's called the constraint, or the bottleneck.

Speed up any other station, and the team ships no faster. The work only piles up in front of the bottleneck, as more open pull requests or more tasks waiting for a release.

So when a change comes out late, fix the line, not the change. The first queue to check sits at the very start of the board.

Too Much in Progress Slows Everything

Every open task waits on the others. Finish before starting.

When each developer holds three or four tasks, each one moves slower, and none of them reaches users. That's how "everyone's busy all day" and "nothing ships" can both be true.

It's the trap of being 90% done on five things. The status reads "A is 60% done, B is 30%", and nothing can be deployed.

The fix is a limit. Mine is one task in progress at a time: finish it, deploy it, then pull the next. A task waiting on someone else is marked blocked, so the board stays honest.

I've led dev teams twice. Both started on Scrum and moved toward Kanban, and both times delivery rocketed. The only meeting that survived was a five-minute daily standup on blockers, and the status lived on the board.

A limit needs a ranked list behind it, or every task arrives marked urgent. Priorities, not scope is that list, and someone has to own the ranking.

With fewer tasks open, the next queue shows up clearly. It's the one after the code.

Big Pull Requests Wait Longest

Review is where many teams lose days. Reviewing is rarely anyone's main job, and on a busy team every reviewer is in the middle of their own task.

So reviews come last, and the cost of one grows with the size of the change. A big pull request waits for an afternoon nobody has. A small one gets read between two other tasks.

Each pull request should be one step, small enough to review in one sitting, with a note on what changed and why. With one task in progress, they arrive one at a time.

AI coding tools tend to push the other way, toward bigger changes. How Should My Team Use AI Coding Tools? covers that side.

After the merge, the change waits once more.

A Manual Release Waits for One Person

Batched, manual or known to one person, the release adds days. Merged changes sit and wait for it and for a round of QA at the end.

The fix is one command. On a product team I helped, a release meant 16 manual actions across three services. They became one Slack command, and the team went to one or two releases a day. Just as important, the team stopped being afraid to release.

Automation alone doesn't remove the wait. A pipeline that waits on manual QA only builds a faster queue. Testing belongs on staging, before the release, so the release only publishes what QA already passed.

Feature flags remove the last wait. Code deploys behind a disabled flag, and turning the feature on becomes a switch. Shipping without breaking things covers the rest of that path.

Sometimes the board, the reviews and the release all move fast, and every change is slow anyway.

Sometimes the Code Is the Queue

Then each change touches files nobody meant to touch.

It shows up as features that each take longer than the last. Fixed bugs come back. Code written fast with AI tools adds its own version: each feature works alone, and nobody checked whether the whole hangs together.

Day to day, the scout rule keeps the mess from growing. Each task leaves the code it touches better than it found it. When the debt blocks a feature, fixing it becomes that feature's first step.

Past that point, a rewrite starts to look tempting. Refactoring usually wins, because a rewrite costs most in the feature freeze. Should I Rebuild My App From Scratch? walks through when it doesn't.

Whichever queue it is, a new developer joins it.

A New Hire Joins the Same Queues

When the time goes to waiting, one more person adds work in progress. Their pull requests join the same review queue, and their changes wait for the same release.

So a hire most likely makes it worse. More work piles up in front of the same bottleneck, and a simple change still takes weeks.

A hire helps in one case the clock also shows: work nobody owns, like an upgrade that keeps losing to features. It slips one sprint at a time, and the missing piece is an owner, not speed.

Top Teams Reach Production Within a Day

DORA's research on software delivery runs a shorter version of the same clock. It measures change lead time, from a commit to that change running in production.

Its 2024 State of DevOps report, from October 2024, sorted respondents into four groups. The top 19% had a lead time under a day and deployed on demand. The bottom 25% took between one month and six months.

The same report found that more AI use went with slower, less stable delivery. For every 25% rise in adoption, throughput was about 1.5% lower and stability 7.2% lower.

Its hypothesis is batch size. Changes grow with the code AI writes, and DORA has found larger changes slower and more prone to break.

How I Find the Wait

When the release is slow, my one-week DevOps audit reads the path from planning to monitoring, in eight areas. It ends in a ranked fix list and the top fix.

When the code is the queue, an architecture audit traces the slowest change and the bug that keeps coming back. Its fix list is ranked by cost.

For a stream nobody owns, I join as a senior on the team and own that stream to production. I work one task at a time, one step per pull request, at about 72 hours per task on average. The weekly price is on the homepage.

What the Team Should Do Now

Measure before you hire, and look for the bottleneck.

Start the clock on every task and run it for a month. At the end, the longest wait is the bottleneck, and it points to its own fix:

1. Before the code: cap the work in progress.
2. In review: shrink the pull requests.
3. Between merge and users: make the release one command.
4. Nowhere in particular: clean the code as part of each task.

A busy team that ships slowly is rarely short of people. Its work is waiting somewhere, and a month of the clock shows where.