Small Releases

XP advocates for small, frequent releases. This was radical in 1999 when annual releases were normal. It's still radical in many organizations.

Benefits of small releases:

Faster feedback: Customers see real software sooner. They can tell you what's wrong before you've built too much of the wrong thing.

Reduced risk: Each release is a small bet. If it fails, you've lost weeks, not months. You can course-correct quickly.

Faster value delivery: Features that are done get used. A feature released today is better than a feature waiting for a big release in six months.

Improved morale: The team sees their work used. Shipping is satisfying. Long release cycles drain motivation.

Better quality: Smaller releases mean smaller changes. Smaller changes are easier to test, easier to debug, and less likely to cause problems.

The right release frequency depends on context, but push for smaller and more frequent than feels comfortable.

Frequency examples:

• Daily (continuous deployment): Every commit goes to production
• Weekly: Release at the end of each iteration
• Bi-weekly: Release after every other iteration
• Monthly: Monthly release cycle

Each step smaller is better, up to the point where release overhead dominates. If releasing takes a full day of manual work, releasing daily is impractical. Fix the release process first.

Signs you're releasing too infrequently:

• Releases are scary (too much changed)
• Integration problems are common (big batches)
• Customers wait months for fixes
• The team has "merge weeks"

Small releases require technical investment:

Automated testing: You can't release frequently if testing takes weeks. Fast, comprehensive automated tests are essential.

Continuous integration: Code must integrate smoothly. Long-lived branches are incompatible with frequent releases.

Deployment automation: Releases must be push-button. Manual deployment steps slow you down and introduce errors.

Feature flags: Incomplete features can be merged but hidden from users. This allows small releases even when features span multiple iterations.

Database migration strategy: Schema changes must be deployable without breaking existing code. Usually this means forward-compatible migrations.

Monitoring and rollback: When something goes wrong, you need to know immediately. And you need to be able to roll back quickly.

These aren't XP practices per se—they're modern DevOps practices that enable XP's original vision of continuous delivery.

The logical extreme of small releases is continuous deployment: every commit that passes tests goes directly to production.

This sounds terrifying. But with the right practices, it's actually safer than big releases:

• Each change is tiny and easy to understand
• If something breaks, you know exactly what caused it
• Rollback is trivial (the last deploy was minutes ago)
• No "release day" stress or after-hours pushes

Continuous deployment requires:

• Very high test coverage
• Very fast builds (10 minutes max)
• Robust feature flags
• Excellent monitoring
• A culture of quality (no cutting corners)

Not every team is ready for this. But every team can move toward smaller, more frequent releases. Start by releasing twice as often. Then twice as often again. See how far you can go.