Back in 2002, when I first started experimenting with Agile and XP (Extreme Programming), both were gaining traction as trendy approaches to software dev.
At the time, XP was a hot topic, but today, and you don’t hear much about it anymore.
Agile: The Broader Umbrella
Agile isn’t a single methodology—it’s a philosophy. It emerged in 2001 with the Agile Manifesto, which prioritized:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile frameworks (like Scrum, Kanban, and yes, XP) were designed to help teams develop software in a way that’s flexible, iterative, and customer-focused.
Key Characteristics of Agile
✅ Iterative and incremental development
✅ Frequent feedback loops
✅ Emphasis on collaboration (with customers and within teams)
✅ Adaptability to changing requirements
Agile is like a loose-fitting jacket—it provides structure but allows for flexibility.
It doesn’t prescribe specific engineering practices, which is where XP originally came in.
Extreme Programming (XP): The Hardcore Engineering Approach
XP, created by Kent Beck in the late 1990s, was one of the first Agile methodologies that defined concrete software engineering practices.
It was extremely disciplined—hence the name—and aimed to improve software quality while adapting to changing requirements.
Key XP Practices
🔹 Test-Driven Development (TDD) – Write tests before writing code.
🔹 Pair Programming – Two developers work together at one workstation.
🔹 Continuous Integration (CI) – Frequent, automated builds and testing.
🔹 Refactoring – Constantly improving code without changing behavior.
🔹 Simple Design – No unnecessary complexity.
🔹 Small Releases – Frequent, incremental deliveries.
🔹 Collective Code Ownership – Any developer can modify any part of the codebase.
🔹 40-Hour Workweek – Sustainable pace over burnout.
XP was all about discipline and technical excellence, but it had some rigid requirements that not all teams were comfortable with.
From My experience, the thing people tend to talk about the most with XP was the Pair-Programming..
Agile vs. XP: Key Differences
| Feature | Agile | XP |
|---|---|---|
| Scope | Broad philosophy with multiple frameworks | Specific Agile methodology with strict engineering practices |
| Engineering Focus | Encourages but doesn’t dictate | Strongly emphasizes coding discipline |
| Management | Adapts to various project styles | Developer-centric, minimal bureaucracy |
| Team Collaboration | Cross-functional, but varies by framework | Strong developer pairing and collaboration |
| Flexibility | High—depends on framework | Less flexible—strict XP rules |
| Adoption Today | Still widely used (Scrum, Kanban, SAFe) | Rare, but some XP practices live on |
Why I personally think XP Faded
1️⃣ Rigid Practices
XP demanded strict adherence to practices like pair programming and TDD, which some teams found exhausting or impractical.
2️⃣ Scrum Took Over
Scrum, with its simple structure (sprints, stand-ups, retrospectives), was easier for businesses to adopt than XP’s strict engineering principles.
3️⃣ XP’s Best Ideas Were Absorbed
Even though XP isn’t commonly used as a full methodology anymore, its best practices—TDD, CI/CD, and refactoring—are still popular.
And if an occasional tricky problem comes up, Pair programming can be a very useful tool in the tool-box.