Modern software teams can learn a great deal from 25 years of Extreme Programming. The core XP practices, including test-driven development, continuous integration, and close collaboration, have proven remarkably durable, and many of them quietly underpin the agile frameworks teams use today. Bloom Group works with enterprises navigating exactly these questions, and the short answer is this: XP’s principles are more relevant than ever, even if the label itself has faded from fashion. Below, we unpack the most important questions modern teams are asking about XP in 2026.
What XP principles have actually survived 25 years of software change?
The XP principles that have survived best are the ones rooted in feedback and collaboration: continuous integration, small releases, collective code ownership, and close customer involvement. These ideas were radical in 1999 but are now considered baseline expectations in most professional software environments. The technical practices, especially automated testing and refactoring, have aged particularly well.
What has faded is the prescriptive, all-or-nothing packaging. Kent Beck’s original framework demanded that teams adopt all twelve practices together. In practice, organizations have cherry-picked what works. Continuous integration became the backbone of modern DevOps pipelines. Refactoring became a standard engineering discipline. The vocabulary shifted, but the substance remained. The principles survived because they solved real, recurring problems: slow feedback loops, fragile codebases, and misaligned expectations between developers and business stakeholders.
How does XP differ from Scrum and modern agile frameworks?
XP and Scrum differ primarily in their focus. Scrum is a project management framework that organizes work into sprints and defines team roles and ceremonies. Extreme Programming is an engineering discipline that prescribes specific technical practices for how code is written, tested, and integrated. Scrum tells you how to organize a team; XP tells you how that team should actually build software.
This distinction matters in practice. A Scrum team can deliver working software in sprints without ever writing a unit test or practicing continuous integration. An XP team, by contrast, is defined by its technical habits. Many modern agile teams blend the two: they use Scrum’s sprint structure and ceremonies as their delivery rhythm while adopting XP’s engineering practices to maintain code quality. SAFe, LeSS, and other scaled agile frameworks have also absorbed XP practices at the team level, which is part of why XP’s influence has outlasted its brand recognition.
What is pair programming and does it still make sense today?
Pair programming is an XP practice where two developers work together at a single workstation, one writing code and the other reviewing it in real time. The roles rotate regularly. The goal is to catch defects earlier, share knowledge across the team, and produce cleaner code through continuous peer review. It remains one of XP’s most debated practices.
Whether it still makes sense depends on context. For complex, high-stakes logic, pair programming consistently produces fewer defects and accelerates onboarding for less experienced developers. For routine, well-understood tasks, the overhead can outweigh the benefit. Remote work has also changed the calculus: distributed teams using tools like VS Code Live Share or JetBrains Code With Me can pair effectively across time zones, but the spontaneity that made in-person pairing valuable is harder to replicate.
The honest position is that pair programming works best as a selective practice rather than a permanent default. Teams that use it strategically, for critical features, architectural decisions, or knowledge transfer, tend to get the most value from it without burning out their developers.
How does test-driven development from XP hold up in 2026?
Test-driven development (TDD) holds up extremely well. The practice of writing a failing test before writing production code remains one of the most effective ways to produce well-structured, maintainable software. TDD forces developers to think about design and intent before implementation, which consistently leads to smaller, more focused functions and cleaner interfaces.
The tooling around TDD has improved dramatically since XP’s early days. Modern testing frameworks across every major language make the red-green-refactor cycle faster and more ergonomic than it was in 1999. Continuous integration pipelines mean that test suites run automatically on every commit, closing the feedback loop that TDD depends on.
Where TDD struggles is in domains with complex external dependencies, legacy codebases without test infrastructure, or teams under extreme time pressure. These are real constraints, not excuses, and experienced engineering teams learn to apply TDD selectively rather than dogmatically. But for greenfield development, TDD remains one of the highest-return engineering investments a team can make.
Which XP practices are most relevant for enterprise IT teams?
For enterprise IT teams, the most relevant XP practices are continuous integration, automated testing, refactoring, and close involvement of a business representative in the development process. These four practices address the most common failure modes in large-scale enterprise software: slow feedback, accumulating technical debt, and misalignment between technical delivery and business need.
- Continuous integration: Prevents the integration nightmares that plague large teams working on shared codebases and is now a non-negotiable baseline in mature engineering organizations.
- Automated testing: Gives enterprise teams the confidence to change and extend complex systems without introducing regressions, which is critical when codebases span years of accumulated logic.
- Refactoring: Keeps enterprise codebases from calcifying into unmaintainable legacy systems, provided it is treated as ongoing work rather than a periodic emergency.
- On-site customer (or business representative): The XP practice of embedding a business stakeholder in the team translates well into enterprise contexts where product owners or business analysts work alongside developers in modern agile setups.
Practices like pair programming and the 40-hour work week (XP’s sustainable pace principle) are also valuable in enterprise settings, though they require deliberate cultural buy-in to implement consistently at scale.
Should modern software teams adopt XP or blend it with other methods?
Modern software teams should blend XP’s engineering practices with whatever delivery framework fits their organizational context, rather than adopting XP wholesale. Pure XP works well for small, co-located teams with a high degree of autonomy and direct access to end users. Most enterprise teams operate under constraints that make the full XP package impractical without adaptation.
The most effective approach is to treat XP as a toolkit rather than a doctrine. Use Scrum or Kanban for delivery cadence and team coordination. Layer in XP’s technical practices, particularly TDD, continuous integration, and refactoring, as the engineering foundation that keeps the delivery cadence sustainable. Add pair programming where the complexity or knowledge-sharing need justifies it.
The teams that struggle are those that adopt agile ceremonies without XP’s engineering discipline. Sprints without automated tests and continuous integration produce fast-moving technical debt, not fast-moving software. XP’s enduring contribution is the reminder that sustainable agility depends on engineering quality, not just process structure.
How Bloom Group Helps Teams Apply XP Principles at Scale
Putting XP principles into practice inside a large organization is rarely straightforward. It requires the right engineering culture, the right tooling, and developers who understand how to apply these practices in complex, real-world environments. That is exactly where we come in.
At Bloom Group, we support mid-size and enterprise organizations in building and scaling high-performance software teams. Here is what we bring to the table:
- Highly educated developers: Every consultant on our team holds an advanced degree in Computer Science, AI, Mathematics, Physics, or Aerospace Engineering, meaning they understand the engineering reasoning behind practices like TDD and refactoring, not just the mechanics.
- Team as a Service (TaaS): We embed experienced engineers into your existing teams or build dedicated delivery teams around your specific technical needs, including greenfield projects where XP practices can be applied from day one.
- Full-stack expertise: From data engineering and machine learning to UX/UI design and cloud infrastructure, we cover the breadth of capabilities modern agile teams need to deliver end-to-end.
- Sustainable delivery: Rooted in values of sustainability and meaningful impact, we help organizations build software practices that hold up over time, not just through the next release cycle.
If your organization is ready to build software teams that combine modern delivery methods with genuine engineering discipline, we would be glad to talk. Contact us to explore how we can support your next project.
Frequently Asked Questions
How do we get started with XP practices if our team has never used them before?
The lowest-risk entry point is continuous integration, since it delivers immediate, measurable value without requiring a cultural shift in how developers write code. Once a CI pipeline is in place, introducing automated testing becomes the natural next step, followed by refactoring as a regular part of the development workflow. Avoid trying to implement all XP practices at once; start with one or two, let the team build confidence and see results, then layer in additional practices like TDD or pair programming where they fit naturally.
What are the most common mistakes teams make when adopting TDD?
The most common mistake is treating TDD as a testing strategy rather than a design discipline — writing tests after the fact defeats the purpose entirely, since the real benefit of TDD comes from letting the test drive the structure of the code before it is written. Another frequent pitfall is writing overly broad or brittle tests that break with every minor change, which erodes confidence in the test suite and causes teams to abandon the practice. Start with small, focused unit tests, keep them fast, and resist the temptation to skip the refactor step in the red-green-refactor cycle.
Can XP practices work effectively in fully remote or distributed teams?
Yes, though some practices require deliberate adaptation. Pair programming works well remotely using tools like VS Code Live Share, JetBrains Code With Me, or Tuple, but teams need to be intentional about scheduling pairing sessions rather than relying on the spontaneous collaboration that happens naturally in a shared office. Continuous integration and TDD are actually easier to sustain in distributed settings because they are tool-driven and asynchronous by nature. The practice that requires the most adaptation is the on-site customer concept — distributed teams should establish clear, frequent communication channels with their business representative to replicate the tight feedback loop XP envisions.
How do we apply XP practices to a legacy codebase that has no existing test coverage?
The standard approach is the "strangler fig" pattern: rather than attempting to retrofit tests across the entire legacy codebase at once, teams write tests for new code and for any existing code they need to modify or extend. Characterization tests — tests that document what the existing code currently does, without judging whether it is correct — are a practical tool for building a safety net before refactoring legacy modules. Michael Feathers' book "Working Effectively with Legacy Code" remains the definitive resource on this challenge and is worth reading before your team attempts large-scale legacy modernization.
What is the difference between refactoring and rewriting, and when should teams choose each?
Refactoring means improving the internal structure of existing code without changing its external behavior, typically in small, safe, incremental steps supported by a test suite. Rewriting means replacing a system or module from scratch, which carries significantly higher risk and cost. The XP position is strongly in favor of continuous, incremental refactoring precisely because it avoids the accumulation of technical debt that eventually forces a costly rewrite. A rewrite is generally only justified when the existing codebase is so structurally compromised that incremental improvement is no longer feasible, or when the underlying technology is genuinely obsolete — and even then, a strangler fig migration is usually safer than a full cutover.
How do we convince leadership or stakeholders to invest time in XP engineering practices like TDD and refactoring?
The most effective approach is to frame these practices in terms of delivery risk and long-term cost rather than engineering ideals. Teams without automated tests and continuous integration accumulate technical debt that slows delivery velocity over time, increases the cost of change, and raises the risk of production incidents — all of which are tangible business concerns. Tracking and presenting metrics such as defect rates, time spent on bug fixes versus new features, and deployment frequency before and after adopting XP practices gives leadership concrete evidence of the return on investment. Pilot the practices on a single team or project first, demonstrate measurable improvement, and use that as the business case for broader adoption.
Is there a point where a team can be "too agile" by focusing too much on process and not enough on engineering quality?
Absolutely, and this is one of the most important warnings embedded in XP's philosophy. Teams that invest heavily in agile ceremonies — sprint planning, retrospectives, daily standups — without an equally strong engineering discipline tend to move fast initially but slow down sharply as technical debt accumulates. This is sometimes called "agile theater": the appearance of agility without the engineering foundation that makes it sustainable. XP's enduring relevance is precisely its insistence that process structure and engineering quality are not alternatives but prerequisites for each other — you cannot sustain a fast delivery cadence without automated tests, clean code, and continuous integration holding the system together underneath.