Symptoms for Developers

These are the symptoms you experience while writing, testing, and shipping code. Some you feel personally. Others you see as patterns across the team. If something on this list sounds familiar, follow the link to find what is causing it and how to fix it.

Pushing code and getting feedback

• Pipelines Take Too Long - You push a change, then wait 30 minutes or more to find out if it passed. Pipeline duration limits how often the team can integrate.
• Feedback Takes Hours Instead of Minutes - You do not learn whether a change works until long after you wrote it. Developers batch changes to avoid the wait.
• Pull Requests Sit for Days Waiting for Review - Your PR is ready, but no one reviews it for days. You start another branch. Now you have two things in flight and neither is done.

Tests getting in the way

• Tests Randomly Pass or Fail - You click rerun without investigating because flaky failures are so common. The team ignores failures by default, which masks real regressions.
• Refactoring Breaks Tests - You rename a method or restructure a class and 15 tests fail, even though the behavior is correct. Technical debt accumulates because cleanup is too expensive.
• Test Suite Is Too Slow to Run - Running tests locally is so slow that you skip it and push to CI instead, trading fast feedback for a longer loop.
• High Coverage but Tests Miss Defects - Coverage is above 80% but bugs still make it to production. The tests check that code runs, not that it works correctly.

Integrating and merging

• Merging Is Painful and Time-Consuming - Your branch has diverged so far from main that merging takes hours of conflict resolution.
• Everything Started, Nothing Finished - The board is full of in-progress items but the done column is empty. The team is busy but throughput is low.
• Work Items Take Days or Weeks to Complete - Cycle time is long and unpredictable. Items sit in progress for days because they are too large or blocked by dependencies.

Deploying and releasing

• The Team Is Afraid to Deploy - Deployments are treated as high-risk events requiring full-team attention. The team deploys less often, which makes each deployment larger and riskier.
• Releases Are Infrequent and Painful - Releases happen monthly or quarterly and require significant coordination, manual testing, and rollback plans.
• Merge Freezes Before Deployments - The team stops merging to stabilize before each release, creating artificial bottlenecks and deferred work.
• Hardening Sprints Are Needed Before Every Release - A dedicated stabilization period is needed before every release because the normal process does not produce releasable code.
• Multiple Services Must Be Deployed Together - Services are coupled so that deploying one requires deploying others at the same time.

Environment and production surprises

• It Works on My Machine - Code passes all your local tests but fails in CI or production. You cannot reproduce the problem locally.
• Tests Pass in One Environment but Fail in Another - The same test produces different results depending on where it runs.
• Staging Passes but Production Fails - The staging environment gives false confidence. Problems that staging should catch reach production.
• Production Issues Discovered by Customers - The team learns about production problems from customer reports instead of monitoring.
• Production Problems Are Discovered Hours or Days Late - Incidents are not detected until the impact has already accumulated.