RACE Programming
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 has two additional constraints greenfield doesn't face: an existing team with established habits, and a live product that cannot stop delivering. The temptation is to "add AI tools" without changing the delivery model — this produces the 46% AI pilot failure rate (Scrum.org): faster code generation into the same broken coordination overhead.

RACE Programming's value in brownfield is not marginal improvement. It is structural change: replace the coordination overhead with a spec-first, prototype-gated delivery model. Where 4× holds: new feature work on the existing product, greenfield features in a brownfield codebase, any work where AI can be delegated 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 existing team for AI Fluency or clear intent to develop it. Non-engineering leads (PO, BA, UX, PM, SM) → AI Product candidates. 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 did not qualify. N = function of qualified candidate count. Start Stints on the next sprint boundary.
  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. Remaining team continues as Scrum teams on 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, works in environments where a hard cutover is politically impossible.
Who

Role mapping for existing team members

Existing role RACE Programming candidate Qualification required
Product Owner Team Principal Business ownership, budget authority, 1-day feedback SLA
Scrum Master / BA / UX Lead / PM / Test Lead AI Product AI Fluency, EUS authoring, Gherkin, EARS NFR — train or confirm within Stint 1–2
Senior / Tech Lead developer ACE Software Engineer (Pit Wall) AI Fluency at senior level. Prototype build ≤ 2 days. ADR ownership.
Mid / Senior developer Pit Crew engineer AI-native execution. 4-gate DoD discipline without reminders.
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 identified and 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
First full Stint. Pit Crew executes approved EUS. Pit Stop Demo at Stint end. Scrum teams (Path B) continue independently on existing backlog.
Month 2
EUS acceptance rate benchmark. Pit Stop pass rate emerging. Path B: evaluate first Scrum-to-Pit-Crew conversion candidate.
How to measure success

Brownfield-specific metrics

EUS acceptance rate
% accepted without revision after prototype review
> 80% by month 2
Pit Stop pass rate
% where staging UAT passes on demo day
> 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 4× holds: 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.