Lots of Commits, No Features: The Productivity Illusion

Your team is exhausted. Commits are flying. Slack is buzzing. JIRA tickets are moving from column to column. But the "Done" column is empty, the roadmap is slipping, and your stakeholders are getting impatient. You have a team that looks busy but is not actually shipping. This is the High Activity, Low Progress syndrome, and it is more common than most engineering leaders want to admit.

This guide will help you diagnose why your team is busy but not shipping, introduce a diagnostic framework for identifying the root cause, and give you specific action plans for each pattern we uncover. Because until you know why velocity is not translating to value, you cannot fix it.

The Trap: Motion vs. Progress

In physics, Work = Force x Distance. If you push a wall for eight hours, you did zero work despite being sweaty and exhausted. Engineering is the same. Activity is not accomplishment.

"A team that merges 50 small PRs a week might ship less value than a team that merges 10 thoughtful ones. Count what reaches users, not what reaches the merge button."

When teams are under pressure, they default to motion because it feels productive. "Look how busy I am!" But motion without direction makes the problem worse. It burns people out while delaying actual delivery.

The HALT Diagnostic Framework

When you see high activity but low progress, the root cause falls into one of four patterns. We call this the HALT Framework because these patterns stop your team from shipping:

Most struggling teams have a combination of these patterns, but one is usually dominant. Diagnosing correctly matters because the fix for each is different. Throwing more developers at a review bottleneck makes it worse. Limiting WIP will not help if the real problem is changing requirements.

Pattern 1: High Churn - The Rewrite Treadmill

"I wrote 1,000 lines of code on Monday and deleted 800 of them by Thursday. That is not productivity. That is expensive learning."

Code churn is the percentage of code that gets rewritten shortly after being written. Some churn is healthy, it means developers are iterating and improving. But excessive churn means something upstream is broken: unclear requirements, changing scope, or architectural issues that force rewrites.

How to Detect High Churn

• Churn rate above 25%: More than a quarter of code being rewritten within two weeks indicates instability
• Same files modified repeatedly: If the same file appears in 5+ PRs in a sprint, requirements are not stable
• High additions + high deletions: A developer with both metrics elevated is churning, not building
• Productive throughput diverging from raw output: Lots of code written but little sticking around

Root Causes of High Churn

Action Plan for High Churn

1. Identify the churn zones: Which files, features, or developers have the highest churn? Focus investigation there.
2. Trace churn to cause: Interview developers. "What caused you to rewrite this?" The answer tells you where to fix.
3. Institute design reviews: For anything taking more than a day, review the approach before coding starts.
4. Freeze sprint scope: Once planning is done, changes go to next sprint unless truly critical.
5. Measure and track: Set a churn target (under 20%) and monitor weekly trends.

For a deeper dive into measuring and reducing churn, see our Code Churn Guide.

Pattern 2: High Abandon Rate - PRs That Never Ship

Every abandoned PR represents wasted effort: hours or days of work that never reached users. Some abandonment is normal (experiments that did not pan out, approaches that proved wrong), but if your abandon rate is above 15%, you have a systemic problem.

Why PRs Get Abandoned

"A PR that sits open for two weeks is not 'almost done.' It is dead. The context is lost, merge conflicts are growing, and the developer has mentally moved on. Close it or merge it. Zombie PRs drain cognitive capacity."

Action Plan for High Abandon Rate

1. Set a PR age limit: Any PR open longer than 7 days gets reviewed in standup. "What is blocking this? Can we help?"
2. Kill zombies ruthlessly: PRs open longer than 14 days get closed. If the work matters, it can be re-started fresh.
3. Address scope creep at the source: Require breaking large work into multiple PRs. Maximum PR size of 400 lines.
4. Track abandon reasons: When closing abandoned PRs, note why. Patterns will emerge that point to systemic issues.
5. Unblock faster: Create explicit SLAs for decisions and dependencies. If blocked for 48 hours, escalate.

Pattern 3: Review Bottleneck - The Waiting Game

According to the 2024 State of DevOps Report, wait time is often the largest component of cycle time. Your developers spend more time waiting for reviews than writing code. And every hour a PR sits waiting is an hour of context that fades from the author's mind.

Signs of a Review Bottleneck

• Wait-for-review time exceeds coding time: Developers finish work in hours but wait days for reviews
• Uneven reviewer distribution: One or two people doing 50%+ of all reviews
• Review queue growing: More PRs opened than merged each week
• Authors doing other work while waiting: Starting new tasks instead of shepherding current ones

Root Causes of Review Bottlenecks

Action Plan for Review Bottlenecks

1. Set and enforce a review SLA: First review within 4 business hours, all reviews complete within 24 hours.
2. Distribute review load: No one should do more than 2x the team average. Actively assign reviews to underloaded reviewers.
3. Make reviews smaller: Enforce maximum PR size. Smaller PRs get reviewed faster and reviewed better.
4. Create dedicated review time: Block 1-2 hours daily specifically for review. Treat it as non-negotiable.
5. Reduce required reviewers: Two reviewers catch 90%+ of issues. Three adds latency without proportional benefit.

For more on optimizing code review, see our Review Load Balancing Guide and PR Size Optimization Guide.

Pattern 4: WIP Explosion - Too Many Plates Spinning

"A developer with four PRs in flight is not four times as productive. They are context switching so much that all four PRs move slower than one would."

Work in Progress (WIP) is the silent killer of team productivity. Every open item represents context that must be maintained. Every context switch costs 20+ minutes of focus recovery. A developer switching between tasks five times a day loses over an hour and a half to transitions alone.

Signs of WIP Explosion

• High open PR count per developer: More than 2 active PRs per person suggests too much parallelism
• PRs opened faster than merged: Growing PR backlog week over week
• Everything in progress, nothing done: Lots of movement across sprint board, few items reaching "Done"
• Long PR ages: Average PR taking 5+ days suggests work getting abandoned mid-stream
• Developers feeling scattered: Complaints about interruptions, difficulty focusing

The Mathematics of Context Switching

Action Plan for WIP Explosion

1. Set explicit WIP limits: Maximum 2 active items per person. New work cannot start until current work is merged.
2. Stop starting, start finishing: Team priority is always to finish in-progress work before picking up new work.
3. Make WIP visible: Put open PR count per person on a dashboard. Social pressure helps maintain limits.
4. Protect focus time: Block 4-hour windows where no meetings or interruptions are allowed.
5. Finish what you start: If blocked on PR #1, the answer is to unblock it, not to start PR #2.

For more on managing focus and context switching, see our Context Switching Patterns Guide.

The Hidden Drain: Shadow Work

Sometimes the team is shipping, but not on the roadmap. They are doing "shadow work" that is invisible to stakeholders but very real to Git:

• Fixing a flaky CI pipeline (again)
• Helping Customer Support manually run SQL queries
• Attending "alignment meetings" that produce no decisions
• Debugging that one microservice that keeps timing out
• Onboarding new team members without allocated time
• Writing documentation because support keeps asking the same questions

Shadow work is not bad work. It is often essential. But if it is not visible, it creates a gap between what stakeholders expect and what gets delivered.

Making Shadow Work Visible

For more on tracking the balance between feature work and maintenance, see our Feature vs. Maintenance Balance Guide and KTLO vs Innovation Guide.

CodePulse Metrics to Check

When diagnosing high activity, low progress, these are the specific metrics to examine in CodePulse:

Action Plan: This Week

Do not try to fix everything at once. Start with diagnosis, then address the dominant pattern.

Day 1: Diagnose

1. Review your Dashboard cycle time breakdown. Where is time being spent?
2. Check Developer Analytics for churn rates and open PR counts.
3. Examine Review Network for review distribution.
4. Identify which HALT pattern is dominant.

Day 2-3: Quick Wins

• If High Churn: Freeze scope for rest of sprint. No new requirements.
• If High Abandon: Close all PRs older than 14 days. Clean slate.
• If Review Bottleneck: Set 4-hour SLA starting today. Enforce it.
• If WIP Explosion: Implement 2-item WIP limit immediately.

Week 2+: Systemic Fixes

1. Institute design reviews for any work taking more than a day. Catch churn-causing misalignment early.
2. Set up progress alerts in CodePulse to catch regression.
3. Review in retrospectives: "Did we ship, or just move things around?"
4. Track the output metric: Features deployed and validated, not activity counts.

Measuring Success: The Efficiency Rate

To know if you are improving, track your efficiency rate:

"The goal is not to do more. The goal is to ship more. When those diverge, you have found your problem."

Conclusion: Ship, Do Not Just Work

High activity with low progress is frustrating for everyone: engineers feel busy but unfulfilled, managers feel confused, and stakeholders feel misled. The path forward is not working harder but working differently.

Use the HALT Framework to diagnose whether your problem is Churn, Abandonment, Review bottlenecks, or WIP explosion. Then apply the targeted fix for that pattern. Measure your efficiency rate to track improvement. And remember: velocity is not the goal. Shipping value is.

For related guidance, see our Engineering Velocity Metrics Guide, Cycle Time Breakdown Guide, and Stop Estimating, Start Forecasting.