Skip to content 
In the early 2000s, Extreme Programming, or XP, felt like a revolution. Not just because agile was new, but because it made development feel human again.
Teams were pairing full time. Tests came before code. Refactoring wasn’t something you saved for a “later” that never came. Features shipped often, feedback loops were tight, and engineers understood not just what they were building, but why it mattered.
Fast forward to today, and XP barely gets mentioned in most teams. You’ll hear about agile, Scrum, Kanban, maybe SAFe if things have gone dark. You might hear a senior dev say, “I write tests before code,” but they won’t call it XP.
So what happened? Why did Extreme Programming fall out of fashion? And is it something we should still be paying attention to?
XP Was Designed for Change, Not for Speed
Kent Beck, who created Extreme Programming, said it best:
“I'm not a great programmer. I'm just a good programmer with great habits."
And that’s what XP tried to build: great habits that made change safe instead of terrifying.
The first XP team worked on a failing payroll system at Chrysler. The code was brittle, requirements shifted every week, and the old way of planning everything up front clearly wasn’t working.
Beck’s approach was simple: lean into the chaos. Instead of resisting change, optimize for it. That meant doing the things we already knew were good, such as testing, refactoring, clean code, collaboration but doing them constantly, deliberately, and together.
What Extreme Programming Looked Like
XP wasn’t a mindset. It was a method.
It introduced 12 practices that were meant to be used together, not picked apart:
- Test-Driven Development (TDD)
- Pair Programming
- Continuous Integration
- Small Releases
- Simple Design
- Refactoring
- Collective Code Ownership
- Coding Standards
- Planning Game
- On-Site Customer
- Metaphor (a shared understanding of the system)
- Sustainable Pace (often called the 40-hour work week)
The strength of XP wasn’t in any one part. It was in how tightly the practices reinforced each other. Tests made refactoring safe. Pairing shared knowledge. Frequent releases kept the team close to real users. The loop was tight, and the feedback was constant.
Why XP Quietly Disappeared
It’s not that XP didn’t work. It’s that it didn’t scale easily.
XP worked best in small teams where everyone sat together, talked frequently, and had access to real users. When agile started getting adopted by larger organizations, XP wasn’t a natural fit. Scrum, with its roles and ceremonies, looked much easier to roll out across departments.
The industry shifted toward frameworks that looked manageable on a slide. XP required culture. It required discipline. It required people to buy in, not just attend meetings.
And let’s be honest. Some people hated pairing. Others pushed back against test-first development. And not every company was ready to give developers that much autonomy or ownership.
What Stayed Behind
Even though the term “Extreme Programming” faded, a lot of its practices stuck around.
TDD is still valued in backend-heavy teams.
CI/CD pipelines are standard across most modern stacks.
Pair programming happens during onboarding or while tackling tricky architecture.
Refactoring is no longer a dirty word.
Sustainable pace is something most teams try to respect, at least in theory.
XP didn’t disappear. It was absorbed. And in some ways, that’s the best compliment you can give a methodology.
Can XP Work in 2025?
Yes, but not copy-pasted from a book. XP has to evolve for how teams work today.
Remote work is the norm nowadays. We don’t sit in the same room as our teammates, let alone the customer. Full-time pairing can feel draining, especially over Zoom. TDD sounds good until you’re prototyping a UI and every test breaks on every animation tweak.
But that doesn’t mean XP is useless. In fact, its focus on clarity, communication, and clean delivery is more relevant than ever.
A modern take on XP might include:
Pairing for complex stories or high-risk areas, not the whole day
Writing tests first on backend logic, but maybe not pixel-perfect UI
Refactoring time built into sprints
Shared ownership through strong code reviews
Continuous delivery with fast rollbacks when needed
XP isn’t a script. It’s a system for caring deeply about what we’re building and how we build it.
What XP Looks Like in Real Teams
Take a company like Monzo, or any fast-moving fintech with a strong engineering culture. They don’t call what they do “Extreme Programming.” But the signs are there.
Features roll out in small, tested chunks
Engineers own the product end to end
Refactoring is not something you fight to schedule
Pairing happens during tough problems
Releases are frequent, safe, and automated
The same is true for a lot of well-run engineering teams. They may not have “XP” written on a whiteboard. But they’re living it quietly and effectively.
Should We Bring XP Back?
If your team struggles with technical debt, late bugs, long QA phases, or unclear ownership, XP offers a path forward. Not a trendy one. Not an easy one. But a proven one.
You don’t need to adopt all 12 practices. But you do need to buy into the mindset: change is constant, quality is a team responsibility, and feedback matters more than prediction.
XP works best when you actually care about how your software is made and not just what it does.
And if that sounds like your team, then yes, XP is worth bringing back. Not as a brand, but as a way of working that still holds up.