Triage Your Problems

• 1: Multi-Symptom Selector
• 2: Team Health Check
• 3: Symptoms for Developers
• 4: Symptoms for Agile Coaches
• 5: Symptoms for Managers

1 - Multi-Symptom Selector

Start with what hurts, then drill into specifics. The selector finds anti-patterns driving multiple symptoms at once.

2 - Team Health Check

This worksheet is designed for a team to use together - in a retrospective, a planning session, or an initial CD assessment. Work through each delivery area and check every statement that describes your current situation. The results show which practices to address first.

3 - 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.
• A Large Codebase Has No Automated Tests - No automated tests means every change is risky and slow. Manual testing cannot keep up with delivery pace.
• Tests Interfere with Each Other Through Shared Data - Shared test data causes tests to fail unpredictably. You cannot trust the results without re-running.
• Test Environments Take Too Long to Reset - Resetting takes so long that you skip local runs or batch changes to avoid the wait.

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.
• Database Migrations Block or Break Deployments - Schema changes couple deployments to manual coordination and downtime windows.
• API Changes Break Consumers Without Warning - Changing an API breaks downstream services because there are no contracts or versioning.
• Deployments Are One-Way Doors - There is no fast rollback, so every deployment carries irreversible risk.

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.
• Setting Up a Development Environment Takes Days - Onboarding friction and undocumented setup steps waste developer time before any code is written.
• Getting a Test Environment Requires Filing a Ticket - Developers cannot self-serve environments, creating wait time before any testing.
• When Something Breaks, Nobody Knows What to Do - Incident response is chaotic because there are no runbooks or clear ownership.
• The Team Ignores Alerts Because There Are Too Many - Alert noise trains developers to ignore monitoring, masking real incidents.

See Learning Paths for a structured reading sequence if you want a guided path through diagnosis and fixes.

4 - Symptoms for Agile Coaches

These are the symptoms you see in retrospectives, stand-ups, and planning sessions. They show up as process friction, collaboration breakdowns, and integration pain. If something on this list sounds familiar, follow the link to find what is causing it and how to fix it.

Work is stuck or invisible

• 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.
• Blocked Work Sits Idle Instead of Being Picked Up - When work is blocked, nobody swarms to unblock it. Items sit in a blocked column until the original assignee returns to them.
• Sprint Planning Is Dominated by Dependency Negotiation - Most of planning is spent coordinating with other teams, not deciding what to build.
• Features Must Wait for a Separate QA Team - A handoff to QA creates a queue that blocks flow and delays feedback to developers.
• Work Stalls Waiting for the Platform Team - Cross-team dependencies create idle time that planning cannot eliminate.

Integration and feedback loops

• Pull Requests Sit for Days Waiting for Review - Work is done but not reviewed. Developers start new branches while waiting, driving up work in progress.
• Merging Is Painful and Time-Consuming - Branches diverge so far from the main line that merging takes hours of conflict resolution.
• The Team Resists Merging to the Main Branch - Developers prefer long-lived branches because merging feels risky. The team lacks the safety net to integrate frequently.
• Feedback Takes Hours Instead of Minutes - Developers do not learn whether a change works until long after they wrote it, which encourages large batches.
• The Team Is Caught Between Shipping Fast and Not Breaking Things - Speed and stability feel like a tradeoff. The team lacks the practices that make both possible.
• Test Automation Always Lags Behind Development - Automation is treated as a follow-up task, so the safety net is always incomplete when it matters most.

Team knowledge and collaboration

• Retrospectives Produce No Real Change - Action items are generated but never acted on. The team has stopped believing retrospectives lead to improvement.
• The Team Has No Shared Agreements About How to Work - There is no team working agreement. Each person follows their own workflow, leading to friction and misaligned expectations.
• The Same Mistakes Happen in the Same Domain Repeatedly - Lessons are not retained. The same types of defects or process failures recur because knowledge is not shared.
• Team Membership Changes Constantly - People rotate in and out. The team never builds enough shared context to improve its own process.
• Delivery Slows Every Time the Team Rotates - New members take weeks to become productive because knowledge lives in people, not in the system.
• The Team Has No Shared Working Hours Across Time Zones - Async-only communication slows integration and makes pairing or swarming impractical.

Delivery pace and sustainability

• Completed Stories Do Not Match What Was Needed - Work is technically done but does not solve the problem. Requirements were misunderstood or changed without feedback loops.
• Stakeholders See Working Software Only at Release Time - Feedback arrives too late to act on. The team builds the wrong thing because stakeholders are not involved until the end.
• Some Developers Are Overloaded While Others Wait - Work is assigned to individuals rather than pulled by the team. Bottlenecks form around specific people.
• Team Burnout and Unsustainable Pace - Process friction, on-call burden, and deployment stress are wearing the team down. Attrition risk is high.
• The Team Is Chasing DORA Benchmarks - Metrics become targets rather than diagnostics, distorting behavior instead of improving it.

See Learning Paths for a structured reading sequence through diagnosis and fixes.

5 - Symptoms for Managers

These are the symptoms that show up in sprint reviews, quarterly planning, and 1-on-1s. They manifest as missed commitments, quality problems, and retention risk.

Unpredictable delivery

• Everything Started, Nothing Finished - The team reports progress on many items but finishes few. Sprint commitments are routinely missed because work that seemed “almost done” stalls.
• Work Items Take Days or Weeks to Complete - Estimates are consistently wrong. A “3-day story” takes two weeks. Forecasting becomes unreliable.
• Releases Are Infrequent and Painful - The organization can only ship quarterly because each release requires weeks of stabilization. Business opportunities are lost to lead time.
• Hardening Sprints Are Needed Before Every Release - The team needs dedicated time to “harden” before every release. This hidden cost is not visible in velocity metrics.
• Leadership Sees CD as a Technical Nice-to-Have - Without leadership buy-in, improvement efforts stall and funding is at risk.
• The Team Is Chasing DORA Benchmarks - Metrics become targets, which distorts team behavior and undermines genuine improvement.

Quality reaching customers

• Production Issues Discovered by Customers - Customers report bugs before the team knows about them. Each incident erodes trust and creates unplanned support work.
• Staging Passes but Production Fails - The team followed the process - tests passed, staging looked good - but production still broke. The process gives false confidence.
• High Coverage but Tests Miss Defects - The team reports strong test coverage numbers, but defects keep reaching production. The metric is not measuring what it appears to measure.
• Production Problems Are Discovered Hours or Days Late - Problems are not detected until the blast radius has grown. The mean time to detect is measured in hours or days, not minutes.
• New Releases Introduce Regressions - Each release breaks something that worked before because testing happens too late in the process.
• AI-Generated Code Ships Without Developer Understanding - Code is merged without the team understanding what it does, creating hidden quality risk.

Coordination overhead

• Multiple Services Must Be Deployed Together - Deploying requires coordination across teams and services. This creates scheduling dependencies and increases the cost of every change.
• Merge Freezes Before Deployments - Development stops before each release so the team can stabilize. This idle time is invisible but costly.
• The Team Is Afraid to Deploy - Deployments are treated as risky events. The team prefers to batch and delay rather than ship frequently, which amplifies risk.
• Releases Depend on One Person - A single release manager creates a bus-factor risk and a bottleneck on every deployment.
• Every Change Requires a Ticket and Approval Chain - Heavyweight change management slows delivery without proportionally reducing risk.
• No Evidence of What Was Deployed or When - There is no audit trail, making compliance and incident investigation harder.

Team health and retention

• Team Burnout and Unsustainable Pace - Process friction, on-call burden, and deployment stress are wearing the team down. Attrition risk is high.
• Merging Is Painful and Time-Consuming - Developers spend significant time resolving merge conflicts instead of building features. This is invisible overhead that slows delivery.
• Pull Requests Sit for Days Waiting for Review - Developers are blocked waiting for reviews. This creates frustration and drives up work-in-progress as they start new things while waiting.
• It Works on My Machine - Environment inconsistency means developers waste time debugging problems that only appear in certain environments. This is preventable friction.

See Learning Paths for a structured path from diagnosis to building a case for change.

What to do next

If these symptoms sound familiar, these resources can help you build a case for change and find a starting point:

• Phase 0: Assess - Map your value stream, take baseline measurements, and identify your top constraints.
• DORA Recommended Practices - The research-backed capabilities that predict delivery performance. Use this to connect symptoms to organizational capabilities.
• Metrics Reference - Definitions for the metrics used throughout this guide, including the four DORA metrics.
• FAQ: How long does the migration take? - Rough timelines for each phase of the migration.
• FAQ: What if our organization requires CAB? - How to move from manual change approval to automated evidence.