Over the past few years I have published a deep-dive on every single activity in the SAFe DevOps Health Radar. This post is the round-the-radar tour: a single page that walks you through all four aspects and all sixteen stages, with the original video for each and a link to the full article. Use it as a map — to find your starting point, to share with your team, or to assess where you are today and where you want to go next.
Please note that everything here is based on the Scaled Agile Framework, which is a toolbox. Take what fits your needs and what solves your problems.
What is the SAFe DevOps Health Radar?#
The SAFe DevOps Health Radar is both an assessment and a process. As an assessment it lets you score your team or value stream from Sit to Fly across sixteen activities and visualise the result as a spider diagram. As a process it describes the full continuous delivery pipeline that turns an idea from the customer into validated value back to the customer.
The radar is structured around four aspects: Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand. Each aspect contains four activities. Together they form the loop that lets you build the right thing, build it right, and learn from what you released. Read the full overview
Continuous Exploration#
The first aspect is where bright ideas from the customer and the business become validated epics with a clear hypothesis, a real customer need behind them, a minimal architecture to prove them, and a prioritised set of features ready for development. The goal of this aspect is alignment between stakeholders so that we build the right thing.
Hypothesize#
Take an idea, turn it into an epic with an Epic Hypothesis Statement, define the MVP, and identify the leading indicators that will tell you whether the hypothesis holds. Read more
Collaborate and Research#
Conduct market and customer research, interview real users, and verify that you are solving the actual underlying problem instead of building what someone happened to ask for. Read more
Architect#
Define the minimal architecture needed to prove the hypothesis. Not the final architecture — the simplest one that lets you validate. Architect for operability from the start. Read more
Synthesize#
Pull it all together: a vision, a roadmap, and a clear set of prioritised features (plus enabler features for the architectural runway) ready for the program backlog. Read more
Continuous Integration#
The second aspect takes prioritised features from the backlog, breaks them into user stories, develops them, and produces verified deployable artifacts in a staging environment. This is where built-in quality, fast feedback loops, and small batch sizes become real engineering practice. Read the full overview
Develop#
Break features into user stories, implement them, commit code to version control, and pair, peer-review, and test as you go so quality is built in, not bolted on later. Read more
Build#
Continuously integrate every commit, run unit tests, run static code and security analysis, and produce a deployable artifact. Use gated commits to keep the trunk green. Read more
Test End-to-End#
Run automated functional and non-functional tests across the full system to verify the artifact behaves as expected before it leaves the integration environment. Read more
Stage#
Deploy the verified artifact to a production-like staging environment for the final round of validation before it is allowed into production. Read more
Continuous Deployment#
The third aspect takes verified artifacts from staging and brings them into production continuously, with the feature toggle off. This is where deployment is separated from release: the change is in production, ready, but invisible to users until the business decides the time is right.
Verify#
Once the artifact is in production, run a subset of the integration tests against it. If anything fails, roll back immediately to the latest stable version. Read more
Deploy#
Bring the compiled code into production with the feature toggle off. This enables dark launches, where new functionality is live but not yet visible. Read more
Monitor#
Use the logging and telemetry built in during Architect and Develop to observe application health, system performance, user behaviour, incidents, and business value in real time. Read more
Respond#
Set carefully designed thresholds on top of monitoring, rehearse disaster recovery, collaborate across teams when something happens, and fix forward or roll back fast. Read more
Release on Demand#
The fourth aspect is what happens after the business says “the time is right” and the feature toggle goes on. It is also where the loop closes: we stabilise, we measure, we learn, and we feed everything back into the next round of Continuous Exploration.
Release#
Switch the feature toggle on so users can actually access the new functionality. Use techniques like canary releases, blue-green deployments, and progressive rollouts to keep risk low. Read more
Stabilize#
Ensure business continuity with disaster recovery, security monitoring (SIEM), continuous monitoring of non-functional requirements, and SLIs, SLOs, and SLAs. SRE plays a key role at high availability targets. Read more
Measure#
Collect both qualitative and quantitative feedback to validate the epic and feature benefit hypotheses. Watch out for vanity metrics and focus on leading indicators that reflect real value. Read more
Learn#
Make the pivot-or-persevere decision based on data, ignore sunk costs, run value stream mapping every quarter, and feed retrospectives and post-mortems back into the pipeline for relentless improvement. Read more
How to use this tour#
If you have never seen the radar before, start at the top with the overview post and work your way down. If you already know the radar and want to assess your team, walk the four aspects in order, score yourself on each of the sixteen stages from Sit to Fly, and add a second column for where you want to be in twelve months. The gap is your transformation backlog.
In many cases you do not need to be a Fly in every activity. A three or even a two is perfectly acceptable, depending on your context. The point is not to maximise every score — it is to identify the bottlenecks that hold back your flow of value and to invest deliberately in closing the gaps that matter.
Key Takeaways#
- The radar is both an assessment and a process. Use it to score your current state and to understand the full continuous delivery pipeline from idea to learning.
- Sixteen stages, four aspects. Continuous Exploration, Continuous Integration, Continuous Deployment, and Release on Demand each contain four activities that build on the previous one.
- Separate deployment from release. This single principle — feature toggles, dark launches, release on demand — is what makes high frequency, low risk delivery possible.
- Architect for operability early. Logging, telemetry, feature toggles, and recovery mechanisms must be built in from the start; they are what make Monitor, Respond, and Stabilize work.
- Close the loop with Measure and Learn. A change that goes to production without validated learning is just shipped code; the radar is designed so insights flow back into the next hypothesis.
- You do not need to be a Fly everywhere. Pick the gaps that matter for your value stream, and use the radar to align the conversation between business, engineering, and operations.