RACE Programming
Audio brief · 2 min
Practice Guide · Brownfield

RACE Programming on an existing product

Live production. Existing team. No hard cutover required. Two transition paths: choose by your organization's change tolerance.

Why

Why brownfield is harder, and still worth it

Brownfield adoption faces two constraints greenfield doesn't: an existing team with established habits, and a live product that can't stop delivering. The temptation is to "add AI tools" without changing the delivery model, which produces the 46% AI pilot failure rate (Scrum.org): faster code generation poured into the coordination overhead it was supposed to remove.

RACE Programming's value in brownfield is not marginal improvement. It's structural change: replace coordination overhead with a spec-first, prototype-gated delivery model. Where the full economics hold: new feature work on the existing product, greenfield features in a brownfield codebase, any work where AI can take a well-formed spec. Where it takes longer: legacy-heavy refactoring with no test coverage, absent or unavailable Team Principal.

What

Two transition paths

Choose based on leadership's change tolerance and available qualified talent.

Fast ROI

Path A: Clean break

  1. Map who can transition. Survey the existing team for AI Fluency or clear intent to develop it. Non-engineering leads (Product Owner, Scrum Master, BA, UX Lead, Test Lead, Project Manager) → AI Product candidates; the Product Manager or business customer → Team Principal, client-side. Tech leads, senior and mid engineers → Pit Wall and Pit Crew candidates. Build the roster before forming teams. No qualification = no RACE Programming role.
  2. Form teams, release others. Qualified roster in hand → form Pit Wall + N Pit Crews immediately. Release or reassign those who didn't qualify. N = function of qualified candidate count. Start the first Stint as soon as the first EUS is specified and priced.
  3. Clean break. Faster ROI, cleaner metrics, no cultural bleed from legacy process. Requires leadership support to make the transition non-negotiable.
Lower risk

Path B: Incremental blend

  1. Form RACE Programming teams from qualified candidates. The rest continue as Scrum teams on the existing backlog.
  2. Convert one Scrum team at a time. As new AI Fluent talent is identified or developed → convert one Scrum team to Pit Crew format, redirect its overhead budget to new delivery capacity.
  3. Full transition when the last Scrum team converts. Slower ROI, lower organizational risk, and it works where a hard cutover is politically impossible.
Who

Role mapping for existing team members

Existing role RACE Programming candidate Qualification required
Product Manager / business customer Team Principal Business ownership, budget authority, 1-day feedback SLA
Product Owner / Scrum Master / BA / UX Lead / Test Lead / Project Manager AI Product AI Fluency, EUS authoring, EARS NFR and the Gherkin acceptance tests, owned here; the Pit Crew Quality Engineer automates them. Train or confirm within Stint 1–2
Senior / Tech Lead developer Forward Deployed Engineer (Pit Wall) AI Fluency at senior level. Prototype build ≤ 2 days. ADR ownership.
QA Engineer / QA Automation Pit Crew Quality Engineer Owns the executable Gherkin as the test source of truth; sets the guardrails AI agents cannot override
Mid / Senior developer Pit Crew engineer AI-native execution. 4-gate DoD discipline without reminders.
(none, net-new) Silicon Software Engineer The AI agent, present in every Pit Wall and Pit Crew. Not a person to staff: the silicon teammate.
No qualification Not assigned a RACE role Reassign or release. Do not form mixed teams.
How

Context mapping before Stint 1

Brownfield codebases require context work that greenfield doesn't. Before the first Stint:

  • AI context audit. What can AI read in your codebase without misinterpreting it? Identify: well-tested modules (AI can execute reliably), legacy modules with no tests (AI needs supervision), undocumented business logic (requires human extraction before delegation).
  • Technical debt strategy. Do not attempt to pay down technical debt and adopt RACE Programming simultaneously. RACE Programming's 4-gate DoD prevents new debt. Existing debt is addressed through dedicated EUS items, prioritized by Team Principal as deliberate investment, not a background task.
  • Prototype scope. For brownfield features, the EUS prototype may need to integrate with existing APIs or data models. Pit Wall identifies integration constraints in the ADR component of each EUS before prototyping starts.

The first 30 days

Week 1
Team qualification survey. Role assignments. Pit Wall pair confirmed. Team Principal availability SLA in writing.
Week 2
First EPR session with Team Principal. Quarterly scope defined. First EUS authored. First prototype built; no production code yet.
Weeks 3–4
The first Stints, roughly four to six of them, because a Stint is two to three days at the floor and stretches up to the client's release cadence. Pit Crew executes each approved EUS, the Team Principal accepts at Stint end, and the Pit Stop deploys to production. Scrum teams (Path B) continue independently on the existing backlog.
Month 2
EUS acceptance rate benchmark. Pit Stop pass rate emerging. Path B: evaluate the first Scrum-to-Pit-Crew conversion candidate.
How to measure success

Brownfield-specific metrics

EUS acceptance rate
% accepted without revision on the first pass, after prototype review
> 80% by month 2
Pit Stop pass rate
% of Stints that reach the Pit Stop with UAT green
> 70% in first 3 Stints
Rework rate
Stories returned after delivery
< 10% after month 2
New debt introduced
DoD gate failures per Stint
Zero tolerance after Stint 3
Path B: Scrum teams converted
Count of Scrum teams converted to Pit Crew format
At least 1 per quarter
Honest caveat
Where the full economics hold: greenfield features in the brownfield product, new modules, engaged Team Principal. Where it takes longer: legacy-heavy refactoring with no test coverage, absent stakeholders, contradictory requirements. We'll tell you which side you're on before a proposal.

See the Framework overview for full role and artifact specifications. If your team currently uses Scrum, the From Scrum guide covers role and ceremony translation in depth.

FAQ

Frequently asked questions

Can you adopt RACE Programming without stopping production delivery?
Yes. The incremental path forms Pit Wall and Pit Crews from qualified candidates while remaining team members continue on existing Scrum backlog. Scrum teams convert to Pit Crew format one at a time as new AI Fluent talent is identified or developed. Full transition completes when the last Scrum team converts.
How do you assess which team members qualify for RACE Programming roles?
Survey existing team for AI Fluency or clear intent to develop it. Non-engineering leads (Product Owner, Scrum Master, Business Analyst, UX Lead, Test Lead, Project Manager) are AI Product candidates; the Product Manager or business customer maps to the client-side Team Principal, not AI Product. Tech leads, senior and mid engineers are Pit Wall and Pit Crew candidates. No qualification = no RACE Programming role. Build the roster before forming teams.
What happens to the technical debt in a brownfield project?
RACE Programming's 4-gate Definition of Done (unit ≥80%, integration, E2E, acceptance, all automated) prevents new debt accumulation. Existing technical debt is addressed through dedicated EUS items in the Executable Product Backlog, prioritized by the Team Principal against new feature work, not separately managed.
Developed in the open

Help develop this

RACE Programming is a working framework, not a final answer. If this was useful, I would like your feedback: what you think is right, what you think is wrong, and what you would change. Disagree with any part, send a better version, or use it in your own work and tell me how it went. It improves faster when people develop it together.

Write to me: paul@raceprogramming.com