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.

Either path has one organizer: the TPM, assigned by leadership. The TPM owns the transition plan and its critical path, the order in which teams move, the dependencies between converted and unconverted teams, the risk register and escalation, and the alignment of the sponsor and the Team Principal's stakeholders. The steps below say where the decisions themselves sit.

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 one Pit Wall and one Pit Crew per separate product immediately; each product is its own engagement, coordinated by the TPM. Release or reassign those who didn't qualify; that call belongs to line managers and leadership, and the TPM schedules it into the plan. The number of teams follows the number of separate products, not the number of qualified candidates. Start the first story 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. The TPM secures that support from the sponsor before day one and holds it through the cutover.
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. The TPM sets the conversion order and puts the dependencies between Scrum and RACE teams on the critical path; the budget move is the Team Principal's call, which the TPM brings to them.
  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 on the first stories
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.
(none, assigned by leadership) TPM Organizes the transition across teams. Not drawn from the Scrum Master or Project Manager, who go to AI Product. Does not manage people.
No qualification Not assigned a RACE role Reassign or release. Do not form mixed teams.
How

Context mapping before the first story

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

  • 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
TPM assigned; transition plan and risk register opened with the sponsor. Team qualification survey. Role assignments. Pit Wall roles confirmed. Team Principal availability SLA in writing, organized by the TPM.
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 stories and the first releases. Each story becomes production-ready in two to three days at the floor; releases follow the client's release cadence. Pit Crew executes each approved EUS, the Team Principal accepts each story, and the next Pit Stop releases it 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; the TPM puts it on the plan.
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 Pit Stops shipped with UAT green and no rollback or hotfix
> 70% in the first 3 Pit Stops
Rework rate
Stories returned after delivery
< 10% after month 2
New debt introduced
DoD gate failures per story
Zero tolerance after the third Pit Stop
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.
Who organizes a brownfield transition to RACE Programming?
The TPM (Technical Program Manager), assigned by leadership. The TPM owns the transition plan, the order in which Scrum teams convert, the dependencies between RACE teams and the Scrum teams still on the existing backlog, the risk register, escalation, and the alignment of the sponsor and stakeholders around the Team Principal. Qualification and reassignment stay with line managers and leadership, budget and priorities with the Team Principal, the product with AI Product.