Scaled Agile

CALMR and DevOps Health Radar: An ART Improvement Cycle

Use CALMR and a DevOps Health Radar to select one evidence-based ART improvement across culture, automation, flow, measurement, and recovery.

CALMR and DevOps Health Radar: An ART Improvement Cycle

The radar starts a conversation; it does not certify maturity

CALMR describes the SAFe DevOps mindset through Culture, Automation, Lean flow, Measurement, and Recovery. A DevOps Health Radar helps participants assess practices across the delivery value stream and identify areas for improvement. Scores are perceptions supported by evidence, not an objective grade or a tool for ranking ARTs.

Prepare with a value-stream slice

Choose one representative path from idea to customer outcome. Invite Product Management, teams, architecture, security, operations, compliance, support, and other people who influence that path. Bring flow distributions, pipeline health, incidents, release outcomes, customer evidence, and recent examples. Different roles should score independently before discussing gaps.

Read the five CALMR lenses together

LensDiagnostic questionPossible evidence
CultureCan people collaborate and surface failure safely?Handoffs, ownership gaps, learning reviews
AutomationWhere does repeatable work still wait or vary?Manual steps, failure rate, maintenance cost
Lean flowWhich queue or batch delays value most?Flow time, WIP, queue age, rework
MeasurementDo measures change a decision?Outcome, flow, quality and operational trends
RecoveryCan the ART restore service and learn quickly?Detection, MTTR, drills, rollback evidence
CALMR improvement cycle connecting culture, automation, lean flow, measurement, recovery, and an ART improvement hypothesis
CALMR lenses help the ART find a constraint; a bounded improvement hypothesis turns assessment into learning.

Select one constraint, not the lowest spoke

The lowest score may not be the limiting condition. Look for a gap that materially affects customer value, safety, quality, or lead time and that the ART can influence. Trace causal evidence. Weak recovery may come from architecture and ownership rather than a missing incident tool; slow automation may reflect oversized batches and policies.

Write a PI-sized improvement hypothesis

State the observed condition, proposed change, expected flow or outcome effect, leading evidence, guardrails, owner, and review date. Example: providing self-service ephemeral test environments for three services will reduce environment waiting in the critical path from days to hours without increasing security exceptions or platform incidents.

Run short learning cycles

  1. Baseline a distribution rather than one average.
  2. Apply the change to a bounded part of live work.
  3. Review evidence frequently with the people doing the work.
  4. Adapt the practice, platform, or policy when assumptions fail.
  5. Share learning and expand only when the result transfers.

Protect assessment integrity

  • Do not tie scores to compensation or transformation targets.
  • Record disagreement and the evidence behind it.
  • Keep the comparison within the ART's own history.
  • Reassess after meaningful change, not to manufacture progress.
  • Include customer and operational outcomes beside capability scores.

SAFe RTE training helps facilitate ART-level improvement and systemic impediment removal. Leading SAFe certification training supports leaders changing policies, funding, and culture beyond the ART boundary.

A useful radar session ends with an owned experiment and a learning date. If it ends with a colorful chart, a long wish list, and no changed work, the assessment has become another reporting layer.

One ART may score automation highly while customer lead time remains poor. Mapping the path reveals a two-week security exception queue and large release batches. The improvement then belongs to lean flow, policy automation, and decision rights, demonstrating why isolated maturity scores should never replace value-stream evidence. The next assessment should inspect the changed delay and customer outcome, not merely ask whether participants feel the automation spoke improved.

Repeat the assessment with enough continuity to compare evidence, but rotate participation so the radar does not become an expert ritual. People closest to recent releases and incidents often see different constraints from transformation leaders. Preserve those disagreements as learning inputs and test them through the improvement experiment rather than averaging them away.