Skills / Software-development

Extreme Programming (XP)

Optimism is an occupational hazard of programming; feedback is the treatment.

Extreme Programming is a software development methodology created by Kent Beck that takes proven engineering practices to their logical extreme — writing tests before code, integrating continuously, designing only what you need right now, and planning in short iterative cycles. Built on five explicit values (Communication, Simplicity, Feedback, Courage, Respect) and a concrete set of primary and corollary practices, XP is the most prescriptive of the Agile methodologies. It is for software developers and small teams who want to ship working software every week without accumulating technical debt or fear of change.

By Kent Beck  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisExtreme Programming (XP)

Input

“I need to add a discount calculation to our checkout service. My team keeps arguing about how to design it before writing any code and we've been…”

Diagnosis

I'm your XP guide — Kent Beck's methodology, applied to your actual code and planning problems.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Write the test first, simplify relentlessly, and make change cost nothing

XP structures software development around five core values (Communication, Simplicity, Feedback, Courage, Respect) expressed through two tiers of practices. Primary practices — Test-First Programming (the Red-Green-Refactor TDD cycle), User Stories, the Weekly Cycle, Quarterly Cycle, Pair Programming, and Continuous Integration — form the daily working rhythm. Corollary practices like Shared Code, Root-Cause Analysis, and Negotiated Scope Contract extend the system. Planning uses the Planning Game: stories are written on cards, estimated by developers, prioritized by the customer, and committed into iteration-sized batches. Simple Design is enforced through four rules in priority order: the code passes all tests, reveals intent, contains no duplication, and uses the fewest possible elements. YAGNI (You Aren't Gonna Need It) acts as the guiding heuristic against speculative design.

The problem

Most teams over-engineer for imagined futures, write code before tests and accumulate regressions, and plan in large batches that collapse when requirements change. XP was created specifically for teams where 'the requirements will change' is a given — not an exception. Generic agile advice tells teams to 'be iterative'; XP tells them exactly how: test first, integrate daily, plan in weekly cycles, keep design simple.

The solution

Apply Kent Beck's prescriptive XP practices to your actual code and planning problems — from a concrete TDD cycle on a real feature to a Planning Game that fits stories into a realistic iteration — so that changing requirements become a competitive advantage instead of a source of technical debt.

You bring

A feature, bug, or requirement you need to implement or plan
Your current team practices or codebase design questions
Iteration or quarterly planning inputs (backlog, velocity, team capacity)
A recurring defect or team dysfunction you want to root-cause

You get

A complete TDD cycle — failing test written first, minimal passing implementation, refactored result — with code examples in your language
User story cards that satisfy all six INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable)
An iteration plan with story estimates, capacity calculation, and negotiated scope
Acceptance tests in Given-When-Then format derived from your stories, serving as a concrete definition of done
A simple design assessment against Beck's four rules, with specific YAGNI violations and refactoring moves named

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your team has spent two days whiteboarding a discount rule engine with a strategy pattern, a rules registry, and a pluggable evaluator — none of it tested, all of it speculative. The original requirement (orders over $100 get 10% off) is still unimplemented. The codebase has three different patterns for similar logic, and the test suite covers only 30% of critical paths. Requirements change every sprint and every change risks breaking something unknown.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Extreme Programming (XP)

“You have a failing test for the exact requirement, a minimal implementation that makes it pass, and refactored code that names its intent. Your iteration plan commits to six INVEST-compliant stories that fit your team's actual velocity. Every story has acceptance tests that define done before a line of production code is written. When a second discount type arrives next sprint, you extend the test suite first — the Red-Green-Refactor cycle makes changing existing behavior a guided, safe operation, not a risk.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Extreme Programming (XP)Claude

Extreme Programming (XP)

I'm your XP guide — Kent Beck's methodology, applied to your actual code and planning problems. I work best when you bring something concrete: a feature you need to implement, a story you're trying to write, a planning session you need to run, or a design decision you're second-guessing. What are you working on?

I need to add a discount calculation to our checkout service. My team keeps arguing about how to design it before writing any code and we've been going in circles for two days.

Two days of design debate without a test is exactly the problem TDD solves. In XP, you don't design your way to clarity — you test your way there. Let's stop the argument and start with the simplest possible failing test.

Before we write anything: what's the most basic discount scenario you need to support right now — not eventually, right now? Something a customer or product owner has actually asked for this iteration.

Orders over $100 get 10% off. That's it for now, but we're pretty sure more discount types are coming.

'Pretty sure more are coming' is YAGNI bait — we're going to ignore that for now and write exactly what's needed today. Here's your Red test:

```pythondef test_order_over_100_gets_10_percent_discount(): order = Order(subtotal=120.00) assert order.discounted_total() == 108.00

def test_order_under_100_gets_no_discount(): order = Order(subtotal=80.00) assert order.discounted_total() == 80.00```

Run these. They fail because `discounted_total()` doesn't exist yet. That's the Red. Now — what's the minimal implementation that makes both tests pass? Not a discount strategy pattern, not a rule engine. The simplest possible code.

I guess just: if subtotal > 100, return subtotal * 0.9, else return subtotal? My team lead is going to hate that.

That's your Green — and it's correct:

```pythonclass Order: def __init__(self, subtotal): self.subtotal = subtotal

def discounted_total(self): if self.subtotal > 100: return self.subtotal * 0.9 return self.subtotal```

Tests pass. Now Refactor — but only to fix real problems, not imagined ones. Apply Beck's four Simple Design rules: Does it pass tests? Yes. Does it reveal intent? The magic numbers `100` and `0.9` obscure it — extract them. Duplication? No. Fewest elements? Yes.

Refactored:```pythonDISCOUNT_THRESHOLD = 100DISCOUNT_RATE = 0.10

def discounted_total(self): if self.subtotal > DISCOUNT_THRESHOLD: return self.subtotal * (1 - DISCOUNT_RATE) return self.subtotal```

When the new discount types actually arrive, you'll have passing tests and clean code as your foundation. The design argument is over.

My team lead will still push for the strategy pattern now since we know more types are coming.

Beck was direct about this: the cost of adding a strategy pattern today — the extra abstractions, the indirection, the code every new teammate has to understand — is real and immediate. The benefit is hypothetical.

When the second discount type arrives, you'll have one concrete implementation and clean tests. Extracting a strategy pattern at that point takes 20 minutes and is guided by two real use cases instead of one imagined one. The design will be better because you waited.

The principle to cite: XP's Simple Design rule says 'fewest elements.' Every abstraction must earn its place by removing duplication from existing code — not anticipated code. That's not laziness, that's discipline.

Reply to Extreme Programming (XP)…

What the skill is doing

01TDD Red-Green-Refactor Guide

02User Story Workshop (INVEST Criteria)

03Planning Game Facilitator

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

EPExtreme Programming (XP)typing…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

I need to add a discount calculation to our checkout service. My team keeps arguing about how to design it before writing any code and we've been goin…9:14✓✓

I'm your XP guide — Kent Beck's methodology, applied to your actual code and planning problems.9:14

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

TDD Red-Green-Refactor Guide

Walks you through the TDD cycle for a specific feature or function: write the smallest failing test (Red), write only the code that makes it pass (Green), then improve the design without changing behavior (Refactor). Works in your language with real code examples.

◦ MethodBased on Beck's fully prescriptive TDD sequence from 'Test-Driven Development: By Example' — the cycle is non-negotiable; tests are always written before production code, and the sequence is Red, then Green, then Refactor.

CapabilityC-02

User Story Workshop (INVEST Criteria)

Transforms a feature idea, user interview note, or product goal into a well-formed user story card that meets all six INVEST properties. Surfaces hidden dependencies, scope ambiguities, and untestable conditions before planning begins.

◦ MethodGrounded in XP's story card practice and the INVEST criteria — stories are the primary unit of planning and customer communication in XP, replacing heavyweight requirements documents.

CapabilityC-03

Planning Game Facilitator

Facilitates an iteration planning session: estimates stories using developer judgment, calculates realistic iteration capacity from velocity, negotiates scope with the customer's prioritization, and produces a committed iteration plan for the weekly cycle.

◦ MethodImplements Beck's Planning Game — the structured ritual where developers estimate (they own cost) and the customer prioritizes (they own value), resolving tension through negotiation rather than top-down mandate.

CapabilityC-04

Simple Design Evaluator

Reviews a design decision, class structure, or architecture choice against Beck's four simple design rules in order: passes tests, reveals intent, no duplication, fewest elements. Identifies YAGNI violations and over-engineering before they become debt.

◦ MethodApplies Beck's four rules of Simple Design from 'Extreme Programming Explained' — the rules are ordered by priority, and 'fewest elements' (YAGNI) is explicitly last, preventing premature abstraction while protecting correctness and clarity.

CapabilityC-05

Acceptance Test Generator

Derives acceptance tests from a user story in Given-When-Then or narrative format, making implicit requirements explicit and creating a shared definition of done between developers and customers before implementation begins.

◦ MethodBased on XP's practice of writing acceptance tests before implementation — acceptance tests are the customer's formal specification and the primary tool for validating that an iteration story is complete.

CapabilityC-06

XP Adoption Roadmap

Assesses which XP primary practices your team is missing, recommends an adoption sequence from lowest-friction to highest-impact, and explains the dependency relationships between practices (e.g., why Continuous Integration must precede Daily Deployment).

◦ MethodDraws on Beck's distinction between primary practices (safe to adopt individually) and corollary practices (which depend on primary practices being in place) from 'Extreme Programming Explained' 2nd edition.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

TDD Cycle Walkthrough

A step-by-step Red-Green-Refactor session for a specific function or feature — includes the failing test, the minimal implementation, and the refactored version with design rationale explaining each move.

OutputD-02

INVEST Story Card

A completed user story with title, narrative (As a / I want / So that), acceptance criteria, INVEST analysis confirming all six properties, and story point estimate range.

OutputD-03

Iteration Commitment Plan

A Planning Game output: prioritized story list, developer estimates, calculated capacity from velocity, negotiated scope boundary, and the committed story set for the weekly cycle.

OutputD-04

Simple Design Audit

A four-rules assessment of a design decision or code structure — identifies which rules are violated, names the specific YAGNI or duplication issue, and proposes the simpler alternative with the minimum change needed.

OutputD-05

Acceptance Test Suite Outline

A set of Given-When-Then acceptance tests derived from a user story, covering the happy path, edge cases, and the explicit definition of done that both developers and customers can verify.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Kent Beck

Kent Beck created Extreme Programming and pioneered Test-Driven Development, both of which reshaped how software is built worldwide. He co-created JUnit with Erich Gamma and was one of the 17 original signatories of the Agile Manifesto in 2001. His books — 'Extreme Programming Explained' (1999, 2nd ed. 2004) and 'Test-Driven Development: By Example' (2002) — are foundational texts in modern software engineering, and he later spent years as a software engineer at Facebook/Meta.

Status · Inspired by Kent Beck’s work — not yet claimed. Are you Kent Beck?

Primary sourceS-01

Extreme Programming Explained: Embrace Change (2nd ed., 2004)

by Kent Beck

Creator of XP and TDD; co-creator of JUnit; Agile Manifesto signatory; author of 'Extreme Programming Explained' and 'Test-Driven Development: By Example'.

Read the original ↗

Citationkentbeck.com

In the build queue

Be first to run it.

Extreme Programming (XP) is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchMy team writes code before tests and we keep breaking things during refactors. Can we do a full TDD session on a real feature — I need to add email validation to our user registration service in Python?