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.
11 minute read
Tag: Process-Gates
Release Trains
Changes wait for the next scheduled release window regardless of readiness, batching unrelated work and adding artificial delay.
11 minute read
Deploying Only at Sprint Boundaries
All stories are bundled into a single end-of-sprint release, creating two-week batch deployments wearing Agile clothing.
10 minute read
Deployment Windows
Production changes are only allowed during specific hours, creating artificial queuing and batching that increases risk per deployment.
11 minute read
Manual Regression Testing Gates
Every release requires days or weeks of manual testing. Testers execute scripted test cases. Test effort scales linearly with application size.
11 minute read
Testing Only at the End
QA is a phase after development, making testers downstream consumers of developer output rather than integrated team members.
11 minute read
Code Coverage Mandates
A mandatory coverage target drives teams to write tests that hit lines of code without verifying behavior, inflating the coverage number while defects continue reaching production.
7 minute read
QA Signoff as a Release Gate
A specific person must manually approve each release based on exploratory testing, creating a single-person bottleneck on every deployment.
11 minute read
Distant Date Commitments
Fixed scope committed to months in advance causes pressure to cut corners as deadlines approach, making quality flex instead of scope.
8 minute read
Undone Work
Work is marked complete before it is truly done. Hidden steps remain after the story is closed, including testing, validation, or deployment that someone else must finish.
6 minute read
Manual Deployments
The build is automated but deployment is not. Someone must SSH into servers, run scripts, and shepherd each release to production by hand.
11 minute read
Ad Hoc Secret Management
Credentials live in config files, environment variables set manually, or shared in chat - with no vault, rotation, or audit trail.
9 minute read
Change Advisory Board Gates
Manual committee approval required for every production change. Meetings are weekly. One-line fixes wait alongside major migrations.
11 minute read
Outsourced Development with Handoffs
Code is written by one team, tested by another, and deployed by a third, adding days of latency and losing context at every handoff.
9 minute read
Compliance interpreted as manual approval
Regulations like SOX, HIPAA, or PCI are interpreted as requiring human review of every change rather than automated controls with audit evidence.
10 minute read
Security scanning not in the pipeline
Security reviews happen at the end of development if at all, making vulnerabilities expensive to fix and prone to blocking releases.
10 minute read
Separation of duties as separate teams
A compliance requirement for separation of duties is implemented as organizational walls - developers cannot deploy - instead of automated controls.
10 minute read
No improvement time budgeted
100% of capacity is allocated to feature delivery with no time for pipeline improvements, test automation, or tech debt, trapping the team on the feature treadmill.
10 minute read
Team Burnout and Unsustainable Pace
The team is exhausted. Every sprint is a crunch sprint. There is no time for learning, improvement, or recovery.
4 minute read
Every Change Requires a Ticket and Approval Chain
Change management overhead is identical for a one-line fix and a major rewrite. The process creates a queue that delays all changes equally.
3 minute read
Work Requires Sign-Off from Teams Not Involved in Delivery
Changes cannot ship without approval from architecture review boards, legal, compliance, or other teams that are not part of the delivery process and have their own schedules.
3 minute read
Hardening Sprints Are Needed Before Every Release
The team dedicates one or more sprints after “feature complete” to stabilize code before it can be released.
4 minute read
Releases Are Infrequent and Painful
Deploying happens monthly, quarterly, or less. Each release is a large, risky event that requires war rooms and weekend work.
4 minute read
Merge Freezes Before Deployments
Developers announce merge freezes because the integration process is fragile. Deploying requires coordination in chat.
3 minute read
Leadership Sees CD as a Technical Nice-to-Have
Management does not understand why CD matters. No budget for tooling. No time allocated for improvement.
3 minute read
Teams Cannot Change Their Own Pipeline Without Another Team
Adding a build step, updating a deployment config, or changing an environment variable requires filing a ticket with a platform or DevOps team and waiting.
3 minute read
Releases Depend on One Person
A single person coordinates and executes all production releases. Deployments stop when that person is unavailable.
4 minute read
Security Review Is a Gate, Not a Guardrail
Changes queue for weeks waiting for central security review. Security slows delivery rather than enabling it.
3 minute read
Features Must Wait for a Separate QA Team Before Shipping
Work is complete from the development team’s perspective but cannot ship until a separate QA team tests and approves it. QA has its own queue and schedule.
3 minute read