Symptoms for Agile Coaches
Dysfunction symptoms that surface in team process, collaboration, and integration workflows - the areas where coaching has the most leverage.
4 minute read
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.