XP Technical Practices

In the last unit you learned to strip waste out of how work flows. But the most expensive waste, defects, keeps flooding back as rework unless you build quality in at the source rather than inspecting it out at the end. That is exactly what Extreme Programming's technical practices do. Four of them form the core: test-driven development, pairing and mobbing, simple design with merciless refactoring, and continuous integration. You won't be writing the tests yourself, but you set the conditions and make the case for these habits. Let's take them in turn.

Test-driven development (TDD) follows a tight loop the XP community calls red-green-refactor. You write a small failing test that describes the behavior you want (red), write the simplest code that makes it pass (green), then clean up the design while the test keeps you honest (refactor). Done repeatedly, it produces two things at once: a growing regression suite and a design that stays testable because it was built to be tested.

The loop runs in three repeating beats:

Then back to Red for the next small behavior — repeat in tight, fast cycles.

The pushback you'll hear is that writing the test first is "extra work." It isn't, and your job is to reframe it.

• Chris: Writing the test first just slows me down. I already know what the code should do.
• Natalie: Sure, for the first hour. But where does most of our rework actually come from?
• Chris: Honestly? Edge cases we find in QA a week later.
• Natalie: Right. A failing test forces you to name that edge case now, while it's cheap, instead of in production.
• Chris: So it's less "extra work" and more "moving the work earlier."
• Natalie: Exactly. Same attention, paid at the point where it costs the least.

Notice the move: Natalie never argues that tests are virtuous. She points to where rework actually comes from and shows that TDD moves that cost earlier. As a delivery lead, don't mandate "tests first everywhere on Monday." Introduce it in one low-risk area, pair on the first attempts, and watch the defect trend.

Pairing puts two people on one task; mobbing puts the whole team on it, with one person driving the keyboard and the rest navigating, rotating regularly. Both look inefficient if you count heads producing lines of code. That is the local-efficiency trap from the last unit wearing a new costume. What pairing and mobbing actually buy you is knowledge that stops living in one person's head, review that happens in real time instead of in a queue, and fewer defects reaching QA at all. They directly attack the relearning and unused-talent wastes you named earlier.

Your move is to make the case against the cost it removes: the bus-factor risk when only one engineer understands a system, slow onboarding, and the review backlog. Then run a real session on real work, not a demo, and let the knowledge-sharing show itself.

These three reinforce each other, so treat them as one discipline. Simple design means building only what the current story needs, not the speculative flexibility someone might want later: that speculation is the "extra features" waste. Refactoring is improving the structure of working code in small, continuous steps, not heroic quarterly rewrites.

What makes both safe is continuous integration (CI): merging to the mainline frequently, every day at least, behind a fast automated build that stays green. Without a trustworthy build, refactoring is terrifying and long-lived branches turn integration into a painful merge event. With it, anyone can improve the design and know within minutes if they broke something. Your job is to protect that: keep builds fast and green, and resist branches that live for weeks.

The throughline of this unit is simple: these four practices interlock to build quality in, so the flow you cleared last unit doesn't silently clog with rework. Several practices follow to make it concrete. You'll pattern-test your judgment on what makes CI genuinely continuous versus CI in name only, draft a TDD adoption plan and refactoring guidelines you could hand a skeptical team, and facilitate a first mob session live. Start with the smallest behavior that proves the point: pick one low-risk story this week and ask two people to pair on it test-first.