Hardening and Stabilization Sprints
Dedicating one or more sprints after feature complete to stabilize code treats quality as a phase rather than a continuous practice.
less than a minute
Anti-patterns related to organizational governance, approval processes, and team structure that create bottlenecks in the delivery process.
| Anti-pattern | Category | Quality impact |
|---|
Dedicating one or more sprints after feature complete to stabilize code treats quality as a phase rather than a continuous practice.
Changes wait for the next scheduled release window regardless of readiness, batching unrelated work and adding artificial delay.
All stories are bundled into a single end-of-sprint release, creating two-week batch deployments wearing Agile clothing.
Production changes are only allowed during specific hours, creating artificial queuing and batching that increases risk per deployment.
Manual committee approval required for every production change. Meetings are weekly. One-line fixes wait alongside major migrations.
Developers throw code over the wall to a separate team responsible for deployment, creating long feedback loops and no shared ownership.
Testing is someone else’s job - developers write code and throw it to QA, who find bugs days later when context is already lost.
Regulations like SOX, HIPAA, or PCI are interpreted as requiring human review of every change rather than automated controls with audit evidence.
Security reviews happen at the end of development if at all, making vulnerabilities expensive to fix and prone to blocking releases.
A compliance requirement for separation of duties is implemented as organizational walls - developers cannot deploy - instead of automated controls.