Continuous Delivery (CD) changes the nature of Agile delivery more than any other engineering practice. When teams can deploy to production on demand, the concept of a "sprint release" becomes optional. When they cannot, sprint velocity becomes meaningless. Here is what Scrum Masters need to understand.
The CI/CD Pipeline: A Non-Technical Overview
Continuous Integration (CI) means developers merge code to a shared branch multiple times per day. Every merge triggers an automated build and test run. If tests fail, the build breaks and the team is notified immediately.
Continuous Delivery (CD) extends CI: every passing build is automatically deployed to a staging environment and is ready to deploy to production with a single approval. Continuous Deployment (no approval required) is the most advanced form — every passing build goes directly to production.
Impact on Scrum
| Practice | Without CI/CD | With CI/CD |
|---|---|---|
| Sprint release | Manual, error-prone, hours of effort | Automated, minutes, low-risk |
| Definition of Done | "Code complete, QA approved" | "Deployed to production" is achievable |
| Sprint Review | Demo from staging environment | Demo of live production functionality |
| Bug discovery | End of sprint integration | Within minutes of code merge |
| Release frequency | Once per sprint | Multiple times per sprint or day |
The Scrum Master's Role in CI/CD Adoption
Scrum Masters do not write CI/CD pipelines — but they are critical to creating the conditions for CI/CD adoption. Key SM contributions:
- Remove infrastructure impediments: CI/CD requires dev, staging, and production environments that mirror each other. Environment mismatches are the most common CI/CD blocker. SMs escalate environment provisioning impediments to leadership.
- Evolve the Definition of Done: As CI/CD matures, the DoD should evolve — from "code complete" to "automated tests passing" to "deployed to staging" to "deployed to production."
- Protect team time for pipeline maintenance: CI/CD pipelines require ongoing maintenance. SMs ensure this work is visible in the backlog and protected from being squeezed by feature pressure.
- Coach on test coverage: CI is only as useful as the test suite. SMs coach teams to treat low test coverage as a technical debt priority.
DORA Metrics and Sprint Health
The four DORA metrics measure software delivery performance: Deployment Frequency (how often you deploy), Lead Time for Changes (time from commit to production), Change Failure Rate (% of deployments causing incidents), and Mean Time to Recovery (how quickly you restore service after failure).
Elite performers (as defined by DORA research) deploy multiple times daily with sub-hour lead times, change failure rates under 5%, and recovery times under an hour. These metrics are increasingly used by engineering leaders to assess team health alongside sprint velocity.