RACE Programming vs DORA
DORA and Accelerate measure delivery performance. RACE Programming is the operating model you adopt to move those numbers, and once an AI agent writes the code, it changes which numbers are worth watching. For the full playbook, see measuring a RACE rollout with DORA.
A scorecard and an operating model
| Dimension | RACE Programming | DORA / Accelerate |
|---|---|---|
| What it is | A prescriptive Agentic SDLC framework | A measurement framework and research program |
| Question it answers | How should we build? | How well are we building? |
| Output | Roles, Stint cadence, Executable User Stories, four Definition-of-Done gates | Five key metrics and a capability catalog |
| What it measures from | Idea to production | Commit to production |
| Relationship | Complementary: adopt RACE Programming, keep the DORA five as guardrails, and read them correctly | |
RACE moves the numbers, and moves which ones matter
DORA measures commit to production. AI collapses that clock, so your throughput metrics go Elite almost by construction and stop being the interesting number. Re-point your instrumentation at two things instead: quality at the Pit Stop, and the idea-to-production clock.
That is not an argument against DORA. Keep the five as guardrails; they still catch a rollout that trades quality for speed. But once execution is nearly free, the numbers that decide your pace are the ones DORA was never designed to see.
How each DORA metric reads under RACE
| DORA metric | Under a RACE Programming rollout |
|---|---|
| Deployment Frequency | Elite by construction: every Stint ends in a Pit Stop, weekly or faster. A floor you now stand on, not the win. Watch the share of Pit Stops that clear all four gates first pass |
| Lead Time for Changes | Run two clocks: execution (EUS entering the Pit Crew to its Pit Stop, in hours) and the RACE-native clock (idea logged to Pit Stop, in days). The gap tells you the constraint is upstream |
| Change Failure Rate | The one that still tells the truth. Controlled upstream by Gherkin acceptance criteria and the four-gate Definition of Done. Target flat or falling as throughput rises; always plot next to EUS per week |
| Failed Deployment Recovery Time | Minutes, not hours. Everything as Code makes rollback a deterministic config revert, not a firefight |
| Deployment Rework Rate (the 2025 fifth key) | Near zero. Each unplanned Pit Stop is a defect that slipped the gates, and the earliest signal the Definition of Done is too loose |
Add these, or you are measuring the half that got easy
| RACE-native metric | What to measure |
|---|---|
| EUS throughput (your real velocity) | Executable User Stories accepted per week, per team. Use it instead of story points and commit counts, both of which break the moment the agent writes the code |
| Idea-to-Pit-Stop lead time | Median time from a Team Principal idea logged to its Pit Stop deploy. Once execution is free, this reflects how fast you turn intent into production |
| Team Principal absorption capacity (the new ceiling) | EUS the Team Principal can specify and accept per week, divided by EUS the Pit Crew can ship. Target a ratio approaching 1; below 1 the client is the bottleneck |
Keep the DORA five as guardrails. Manage to EUS throughput, the idea-to-production clock, and absorption capacity. DORA tells you the old bottleneck is gone; these tell you where the new one is.
Measuring a RACE rollout with DORA → · Read the framework → · More comparisons →