• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Continuous Value Flow is embedded in design and operations

Purpose and Strategic Importance

Continuous Value Flow means every change – big or small – moves through an automated pipeline from merge to production in a consistent, observable, low-risk fashion. Embedding this outcome ensures teams deliver user value faster, recover from failures more quickly, and maintain a high bar on quality.

Outcome Statement

“All code changes are built, tested, packaged, deployed, and verified in production with zero-touch pipelines and safety controls, achieving a lead time for changes under 24 hours and a change failure rate below 5%.”

Strategic Impact

  • Shorter Lead Times: Teams ship features and fixes in hours, not weeks.
  • Higher Confidence: Built-in quality gates (tests, linting, security scans) block bad code automatically.
  • Resilience by Design: Observability and automated rollbacks catch and correct production issues immediately.
  • Scalable Delivery: Repeatable, self-service pipelines empower any team to deploy on demand.

Risks of Not Achieving This Outcome

  • Long Release Cycles: Manual handoffs and delays erode agility.
  • Inconsistent Quality: Without automated gates, defects slip into production.
  • Slower Recovery: Lack of observability and rollback tooling extends outage times.
  • Team Bottlenecks: Release and ops teams become chokepoints.

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture Teams rely on manual releases with little confidence in automation.
Changes are infrequent and high-risk.
Process & Governance No defined release cadence or change process.
Quality gates and rollback steps are missing.
Technology & Tools Builds and deployments are triggered manually.
CI/CD tooling may be ad hoc or missing.
Measurement & Metrics No visibility into lead time, failure rate, or deployment frequency.
Recovery is reactive.

Level 2 – Managed

Category Description
People & Culture CI is adopted for some services.
Developers start integrating code more frequently.
Process & Governance Release processes are repeatable but still manual.
Environments are semi-standardised.
Technology & Tools CI pipelines run on commit or merge.
Deployment automation is limited or triggered manually.
Measurement & Metrics Basic visibility into pipeline success/failure.
Some awareness of time to deploy.

Level 3 – Defined

Category Description
People & Culture Teams use CI/CD pipelines confidently.
Delivery is seen as a team responsibility.
Process & Governance Releases follow a clear, automated path to production.
Rollback procedures are known.
Technology & Tools End-to-end CI/CD pipelines exist.
Tests, builds, and deployments run automatically.
Measurement & Metrics Lead time and change failure rate are monitored.
Data is used for retros and planning.

Level 4 – Quantitatively Managed

Category Description
People & Culture Teams use metrics to drive improvement.
Post-deployment telemetry informs future changes.
Process & Governance Deployment cadence, rollback rates, and recovery time are tracked and governed.
Technology & Tools Canary releases, automated rollbacks, and progressive deployment are applied.
Measurement & Metrics All four DORA metrics (LTfC, CFR, DF, MTTR) are tracked.
Trends are reviewed regularly.

Level 5 – Optimising

Category Description
People & Culture Teams actively experiment with delivery approaches.
Observability informs product decisions.
Process & Governance Feedback loops across delivery stages are fast, closed, and used to adapt strategy.
Technology & Tools Pipelines self-heal and optimise through anomaly detection, adaptive alerts, and auto-remediation.
Measurement & Metrics Metrics drive platform and process evolution.
Continuous improvement is embedded.

Key Measures

  • Lead Time for Changes: Time from commit to successful production release
  • Change Failure Rate: Percentage of releases that trigger rollbacks or hotfixes
  • Deployment Frequency: How often production deployments occur
  • Mean Time to Recovery (MTTR): Time to restore service after a failed deployment
  • Pipeline Health: % of pipeline runs that complete end-to-end without manual intervention
Associated Policies

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering