Extreme Programming (XP) is an agile software development method that emphasizes collaboration, customer involvement, and adaptability. As a service company, it shifts part of the efforts upstream of the mission to avoid late and costly corrections, and participates in the development of the skills of junior profiles.
In a digital services company, the quality of the code delivered is not only a matter of technical cleanliness: it decides the profitability of an assignment. A defect that goes unnoticed during development ends up with the customer once the software is in use. It must then be corrected, and this correction was neither foreseen nor budgeted. At a fixed rate, it is deducted directly from the project's margin. In the management sector, it erodes the client's trust, multiplies assets and weakens the renewal of the mission.
Extreme Programming (XP) is an agile method of software development created by Kent Beck in the late 1990s. It takes two principles to the extreme: technical quality and continuous feedback. Its logic: invest more during the design of the code, through pair programming (two developers on the same workstation) and tests written before the code, to pay much less downstream, where a defect costs the most to repair.
🔎 Key elements to remember
- Many XP practices are already standard in IT Services (continuous integration, automated testing, refactoring); Systematic pair programming, the on-site customer and the metaphor remain rare.
- XP combines with Scrum, it does not replace it: Scrum organizes the work, XP brings the engineering practices (testing, pair programming, continuous integration) that guarantee the quality of the code produced in the sprint.
- A defect is all the more expensive the later it is found: on a 50-day package sold with an 8-day margin, 8 days of unplanned recovery are enough to erase all the margin.
- Pair programming and collective responsibility reduce dependence on a single knowing: knowledge spreads throughout the team, so that an absence no longer blocks the mission.
- At a flat rate, it is the engineering practices that protect the margin (testing, pair programming, refactoring), not the agile framework itself; In the management company, the gain can be seen above all in reputation and in the renewal of the mission.
What is Extreme Programming (XP): Values and Practices
Extreme Programming is based on five values (communication, simplicity, feedback, courage, respect) broken down into twelve engineering practices. According to the Agile Alliance, XP is the most accurate agile framework on how to build software: where other methods talk about organizing work and teams, XP explains how to write, test, and deliver code. (source: Agile Alliance)
The Five Values of Extreme Programming
These five values guide all XP practices.
- Communication. XP circulates information through direct exchange (oral, whiteboard, pair programming) rather than through heavy documentation, because most project drifts come from a misunderstanding of the need, not from a technical problem. On a fixed-price mission, a feature developed alongside the request, it is non-rebillable product time that will have to be taken back.
- Simplicity. Build the simplest thing that meets the need of the moment, without coding the functions "just in case". Each anticipated feature that the customer has not ordered consumes development budget for an uncertain value.
- Feedback. Look for feedback early and often: Testing returns the status of the code continuously, frequent deliveries the customer's opinion at each iteration. At a fixed price, this short loop protects the profitability of the mission: a gap in understanding identified at the first delivery is corrected in the scope already sold, while the same gap discovered at the final acceptance date requires a takeover not provided for in the budget.
- Courage. Dare to throw away code that doesn't work rather than patch it up, refactor a fragile part, tell the truth about real progress even when it is disturbing. An overrun announced early is still renegotiated with the customer; The same hidden overage until delivery results in unbilled days.
- Respect. Each member respects the work of the others. This is the concrete condition of pair programming and collective responsibility for code: without it, no one accepts that a colleague modifies "their" code, and knowledge remains locked in a single head.
The twelve practices of XP
The five values translate into twelve concrete practices, the "how" of XP. Three families emerge: planning, the way of designing and writing code, and the organization of the team. Each technical term is glossed at its first occurrence.
| Planning game | Classify features by value, have them estimated by the team, and then plan in short iterations. It is the continuous negotiation between scope, cost and deadline, redone at each iteration rather than just once at the beginning. |
| Small deliveries | Deliver a version that runs every one to three weeks rather than a final jackpot. The value arrives early, the customer tests in real life instead of validating on plan, and the risk of going in the wrong direction decreases. |
| Metaphor | Use a common vocabulary and image to describe the system, so that developers and customer speak the same language and avoid misunderstandings about what needs to be built. |
| Simple design | Design just the right amount to make the tests pass, without over-engineering. We enrich the design when the need really arises, not before. |
| Tests | Write automated tests (unit and acceptance), replayed with each change, which immediately signal a regression. This is the foundation of Test-Driven Development (TDD). |
| Refactoring | Continuously improve the internal structure of the code without changing its behavior, to prevent technical debt from accumulating and slowing down subsequent developments. |
| Pair programming | Two developers on one workstation: one writes, the other proofreads and anticipates edge cases, with regular rotation. The review is done at the source, and knowledge is shared in real time. |
| Collective responsibility for the code | The code belongs to the whole team: everyone can modify it, which reduces dependence on a single knower and blocking when that person is absent. |
| Continuous Integration | Merge your work into the common database several times a day, with automatic build and testing, to detect conflicts and regressions right away rather than at the end. |
| Sustainable pace | Refuse chronic overwork. A rested team makes fewer mistakes and lasts for the duration of a long mission; The permanent over-speed ends up paying for itself in bugs and turnover. |
| On-site customer | A customer representative available to answer, arbitrate, and validate, speeding up decisions and avoiding weeks of waiting on a scope issue. |
| Coding rules | Shared writing conventions that make the code homogeneous and readable by all. This is the condition for anyone to be able to take over someone else's code, and therefore for pair programming and collective responsibility. |
Of these twelve practices, four carry the bulk of the economic gain in service companies: pair programming, testing, continuous integration and refactoring. They are the ones who shift the effort upstream and reduce the recovery.
Which are already standard in IT Services, which remain rare
In 2026, a modern development team is often already applying some of Extreme Programming without naming it. Continuous integration, automated testing, refactoring and coding rules have become industry standards, driven by current tools and uses.
Three practices remain much rarer, each for a specific reason. Systematic pair programming comes up against the perception of a double cost, that of two developers paid for a single task. The customer who is truly available at all times requires a dedicated contact person that few customers agree to mobilize full-time. Finally, metaphor is often considered too abstract and abandoned in practice.
Adopting XP rarely means reinventing everything. It is most often a question of formalizing and completing what the team is already doing halfway, by adding the missing practices that make the difference in quality.
Extreme Programming, Scrum or Waterfall: What Place in Project Management?
Among project management methodologies, these three approaches are not on the same level, and confusing them leads to shaky choices. At the project cycle level, there are two opposing options: sequencing tasks in waterfall, where each phase waits for the previous one to be completed, or moving forward in iterative cycles via an agile method such as Scrum. XP is not a project cycle: it is a set of engineering practices that are grafted onto an iterative cycle. XP therefore complements Scrum, but does not apply well to a project organized in a cascade, where the perimeter is fixed from the start.
Can you combine XP and Scrum?
Yes, and it's even the most common combination to build more successful agile teams. Scrum organizes work (sprints, roles, pace) without saying how to code; XP provides just these engineering practices. The two respond to each other: Scrum frames the sprint, XP guarantees the quality of the deliverables within this project organization.
"Scrum is just a framework for product development, a container in which you can add other practices. XP is one of those [code production] practices that can be applied within the Scrum framework. (Source : scrum.org)
However, these practices must be added, otherwise we will fall into "ceremonial Scrum". A team that adopts Scrum rituals (sprints, daily scrums, reviews) without implementing the best practices provided by XP (automated testing, continuous integration, refactoring, etc.) will accumulate technical debt and, in the long term, have to compensate for it by drawing on its project margin. Indeed, when the code is not tested or cleaned up as it happens, each sprint piles new features on a shaky foundation, and the slightest evolution requires more and more time. The team has the appearance of agility, but without the technical quality that makes it sustainable, and that makes it possible to avoid project drifts. (source: Mountain Goat Software)
XP vs Scrum vs Waterfall Comparison Table
The table below summarizes what each approach organizes and the type of mission where it is suitable. It shows that XP is superimposed on Scrum rather than replacing it, and that the cascade is only suitable for truly stable perimeters.
| What it is | A way of sequencing the project | A way to organize the team and the rhythm | A way to build the code |
| Level | Project management | Project management | Engineering (in code) |
| Answer the question | In what order and when to deliver? | Who does what, at what pace? | How do you produce reliable code? |
| Dealing with flaws | Acceptance at the end of the project | No clean mechanism | Continuous detection (testing, pair programming, continuous integration) |
| Relationship to the other two | Alternative to agile | Combines with XP, opposes waterfall | Grafts into Scrum, opposes the waterfall |
How much XP costs in project management, and what it protects on the margin side
XP shifts the development effort upstream. We invest more during construction (pair programming on the high-risk parts, written tests before the code) to pay much less in correction and technical debt afterwards. The additional cost apparent at the outset is reimbursed downstream, where a defect costs the most to repair. It remains to be seen how much each practice really costs, and under what conditions it is profitable.
Is pair programming, or paying two developers on the same task: is it profitable?
Two developers on the same task give the impression of multiplying project costs. This is the main obstacle to the adoption of pair programming, and it is based on a miscalculation: believing that producing code is just writing it. However, most of the time is spent elsewhere: designing the solution, anticipating edge cases, tracking down errors before they reach production. In pair programming, only one developer produces the code, but both think about its design, and the proofreading is done at the same time, at the moment the error is created rather than weeks later. On complex or highly technical projects, this design + continuous review approach greatly reduces the risk of defects, and therefore the direct costs (long correction because they are out of context) and indirect costs (delivery delays, code regressions) that go with it.
In addition to this continuous rereading, there is a less visible effect: a code written by two people is never known to a single person. However, this double benefit is not automatic. Hannay's meta-analysis, which aggregates eighteen empirical studies, concludes that pair programming is "not uniformly beneficial": it improves quality but increases total effort, and its value depends on the context (source: The effectiveness of pair programming: A meta-analysis, 2009). Pair programming should therefore be reserved for the subjects where it pays off the most: the 20% of high-risk tasks (payment, security, data migration) that make up 80% of the project's difficulty, and the integration of junior profiles. To find out if pair programming reimburses its cost on a given mission, you have to track the time by mission and report it at the margin.
A senior developer in pair programming with a junior on a critical billing module spots a design error before it goes into production, and trains the junior in the process. The same junior alone on this module would probably have produced a code that was apparently correct, but to be completely redone after the first customer incident.
Does writing tests before coding really slow down deliveries?
At startup, yes. Test-driven development (TDD), which involves writing the test before the code it needs to validate, costs around 15-35% more upfront development time. But this additional cost is reimbursed as soon as the code has to last or evolve: the density of defects before delivery drops by 40 to 90% compared to comparable teams without TDD, on four industrial teams monitored at Microsoft and IBM (source: Nagappan et al. study).
The gain is cumulative over the life of the code: each test remains a net that allows the code to be modified later without breaking the existing one, whereas a team without tests slows down as the database grows. The scientific literature still describes the results of TDD as "mixed" depending on the context, and this nuance counts: TDD is especially profitable for code that evolves often. On disposable code, a mock-up, or a quick idea test, writing the tests first is pointless.
On a module that is likely to change often, a developer can reorganize the code in depth without fear: at the slightest broken behavior, a test immediately fails and points to the regression. Without this net, the same modification becomes a gamble, and the team ends up no longer daring to touch the fragile code.
In a service company, this case is the norm rather than the exception. A large part of what you deliver is made to last and evolve: a product that the customer will use for years, an application that you then take over for maintenance (the TMA, i.e. the maintenance and evolutions of a software already delivered). This is exactly the field where TDD is most profitable.
The true cost of a default and technical debt on an IT project
A defect costs all the more late it is found. Corrected in design, it can be fixed in a few minutes of discussion; Discovered in production, it involves analysis, correction, non-regression tests and redeployment, often in a hurry and under pressure from the customer. This principle is old and constant. The precise multipliers that are often associated with it (6×, 15×, 100×) circulate everywhere but have no verifiable primary source, so it is better to stick to the mechanism. Two figures, on the other hand, are solidly established: nearly 50% of the total cost of software is used to find and correct defects, making it the largest expense item in the history of software (source: An Ounce of Prevention); and TDD reduces defect density by 40-90% (Nagappan et al., 2008). A team that aims for quality therefore goes faster and costs less, against intuition, because it does not keep falling behind it. XP practices are among those that produce this reduction.
On August 1, 2012, the American broker Knight Capital deployed a new version of its trading software, but forgot to install it on one of its eight servers. This server continues to run an old piece of code that has never been deleted, which wakes up and sends out erroneous orders in a burst on the markets. Without tests or safeguards to stop it, the company loses about $440 million in 45 minutes and almost goes bankrupt. Continuous integration, automated testing, and the simple removal of obsolete code, all XP practices, could have intercepted these orders before they left. (source: SEC, Release No. 34-70694)
The amount is out of the ordinary, but the mechanism is reproduced on the scale of any mission. A bug not caught during development ends up with the customer once the software is in use. It must then be corrected, and this correction no one had foreseen or quantified: it is additional work, in pure waste. According to the contract, this loss does not fall into the same pocket.
- At a fixed rate, each day spent repairing a bug that has already been delivered is a day worked on but not paid: it is deducted directly from the project's profit. On a 50-day package sold with an 8-day margin, 8 days of unplanned recovery are enough to erase all the margin and tip the mission into balance, or even loss.
- In the control room, the correction is invoiced to the client, so it does not weigh on the current mission. But the customer sees the bugs piling up, loses confidence and risks not renewing the mission. The real cost is played out there, on future contracts that are soaring, much more than on the hours of correction.
Putting a little quality upstream (pair programming on the parts at risk, automated tests, continuous integration) therefore means protecting the margin of the mission, not encumbering it, provided that you know how to calculate the profitability of a project to verify it.
The effect of XP on the resource planning and the profitability of a project in IT Services
Beyond the quality of the code, Extreme Programming acts on two well-known weaknesses of a development mission: the dependence on a single knower and the slow rise of junior profiles. Collective responsibility and pair programming spread knowledge within the team. An absence no longer blocks the mission, and a junior becomes autonomous more quickly, therefore easier to staff.
Less reliance on specialized technology profiles
Without XP, a skill or technology known to a single person becomes a sticking point as soon as that person is absent. The sole developer goes on leave the week of delivery, and the team finds itself unable to touch "their" module without risk.
Pair programming and collective ownership of code defuse this risk by continuously disseminating knowledge. If the developer who masters a subject goes on leave, a teammate who has already coded in pair programming with him on it takes over without interrupting the mission. Collective responsibility here has a direct effect on resource management: by ensuring that any part of the code is known by at least two people, it cushions the hazards (illness, holidays) and limits the costs of turnover, since the departure of a developer no longer takes with him knowledge that no one else holds. (source: Véronique Messager, Gestion de projet agile, Eyrolles, p. 197-199)
On the project management side, the gain is clear and measurable: the absence of a key profile no longer causes the mission to stall or derail its schedule, because the knowledge is shared with at least one other person. The project is progressing despite the vagaries of HR. This mechanism operates at the level of the mission; it should not be confused with the utilization rate of the company, which is first and foremost driven by the pipe and the filling of schedules.
Faster skills development of junior profiles
Senior/junior pair programming transfers knowledge continuously, in the very act of coding. The junior produces a better quality code, which is less often taken up by the senior, and becomes autonomous faster than by learning alone in his corner. Side resource planning, this effect has a direct value: a junior who has become autonomous earlier can be mobilized for a wider range of missions, including more demanding missions with higher billable value.
Without peer programming, a junior placed alone on a subject that is too specific produces code to be taken up again and takes a long time to become autonomous. He must first be trained in the project and in technology, often during his mission time, before being able to position him on demanding subjects. Pair programming shortens this path by compressing the learning phase.
However, this transfer has a cost that must be managed, not let slip away. In concrete terms, it is necessary to provide a framework in terms of time and budget for the critical tasks concerned, i.e. to clearly limit them in the workload plan, so that the investment in training remains controlled and legible in the monitoring of the mission rather than diluted in a diffuse overrun.
At the level of the engagement portfolio
What is at stake in a mission can also be seen at the level of the portfolio. Missions that are less dependent on a senior profile with key skills, and less exposed to budget overruns because they are more qualitative, result in fewer projects in the red zone at the mission portfolio review and in a workforce less tied up on rescue. Employees who have been freed from catching up become available again to produce billable value.
A reservation is necessary not to oversell the method: the good code practices provided by XP are beneficial for the company, but their influence on the margin remains indirect, they reduce a risk without guaranteeing a quantified gain. The calculation is done mission by mission, weighing the time invested upstream (anticipating tests, working in pair programming on the sensitive parts, where the biggest gains lie) against the probable cost of an error repaired downstream. Only a follow-up of time and margin by mission makes it possible to decide it, instead of estimating it with a wet finger.
When to adopt XP, and when it's not the right choice
Extreme Programming is at its best when needs change quickly, the team is tight, and tests are automatable. It does not fit well on an audit mission, pure consulting or a disposable project. And the contractual model, whether governed or fixed-price, changes the economic equation of the method, without ever disqualifying it.
Does your context lend itself to Extreme Programming?
XP gives its full effect under four cumulative conditions. Together, they transform the additional cost of practices into profitable quality. Absent, this additional cost is not reimbursed and the method becomes a burden.
- Needs that evolve along the way. XP was designed for projects with changing requirements: a customer with no fixed product idea, features that change every few months. This is exactly where it succeeds when the cascading cycle fails, because it absorbs change in short iterations instead of suffering it at the end of the project, when everything is already frozen.
- A tight team, from 2 to 20 people. XP is calibrated for small groups: 2 to 12 developers, about twenty at most. The method does not hold up on a massive workforce: beyond that, the work in pair programming and the collective responsibility of the code are diluted, and the direct communication that is its strength becomes impractical.
- Automatable testing. XP assumes the ability to write automated unit and acceptance tests, those programs that verify by themselves that an evolution of the code always gives the right result. They are indispensable at the time a developer reorganizes code (refactoring) or merges their work with that of the team (continuous integration), because they immediately signal if something has broken. Today, there are few projects that are not testable; But without this testability, many errors are not seen until late, in acceptance or production, where correction costs the most.
- A customer who is truly involved. XP relies on continuous communication between developers, managers and customers, to arbitrate the scope, negotiate deadlines and validate functional tests. The method requires a strong discipline and a constant rhythm of exchange. Without an interlocutor available to decide, the feedback loop seizes up and the method loses its engine.
Contract management or fixed price: what's in it?
The contractual model changes what XP earns, and here we must distinguish three things that are often confused when we say that "a lump sum does not lend itself to agile".
In the case of fixed prices, the distinction is decisive:
- The contractual framework. The package freezes the perimeter upstream, in exchange for a firm price. The agile method in the strict sense, which assumes shifting needs negotiated on a continuous basis, therefore does not apply well to this framework. This is true, and this is what we are talking about when we say that forfeit and agility are difficult to reconcile.
- Engineering practices. Automated testing, pair programming on at-risk parties, continuous integration, and refactoring, on the other hand, apply perfectly to a package. This is even where they bring in the most money: each defect avoided upstream is one less day of unbilled trade-off, and therefore a day of margin preserved. The contractual framework restricts agility; it does not restrict quality practices.
- Billing for pair programming. At a fixed price, the customer buys a deliverable, not hours. He doesn't see, and doesn't have to see, how many people are working on a task. Putting two developers on a critical module is an internal choice of quality, invisible to the customer and without impact on the price sold.
A simple way to reconcile the flat-rate framework with the agile mindset: treat each backlog feature as a mission in its own right, with its own short deliveries and tests defined beforehand. We thus introduce XP practices and a part of iterative without reopening the entire contract.
Invoicing in Stafiz: turnover in the field and project margin per mission.
In the control room, the client pays for the time spent. A defect corrected later is potentially billable, according to the terms of the contract, so the quality does not gain a margin on the current assignment. Its interest lies elsewhere, and it is very real:
- Reputation and renewal. Reliable deliveries, few bugs in production, that's what makes the mission renew and recommend you. This is the most solid lever, the one that weighs the most on turnover in the medium term.
- Pricing power. A team with a reputation for reliability stands for better average daily rates (ADR) on its missions and subsequent renewals. The gain comes from the reputation that allows for a better rate: you charge for days, not a code throughput.
- resource planning. A consultant released earlier by a well-conducted mission can be staffed more quickly on the next one, provided that it is consistent with the business opportunities. The downside is real: without a mission behind it, finishing faster even reduces the number of days billed.
When should you not start?
XP doesn't make sense everywhere, and imposing it at the wrong time costs more than it brings in.
- Too large a squad. On a large team, knowledge is diluted instead of allowing targeted skills development, and collective practices become unmanageable.
- Client that refuses peer programming. If the client does not agree to see two profiles, a senior and a junior, on the same task, the cost constraint becomes a blocker, especially in the control room where the number of people invoiced is visible.
- Customer feedback too slow. Without quick responses from the customer, the feedback loop no longer works and XP loses its engine.
- Pure audit or consulting mission. When there is little code to produce, most XP practices simply have no purpose.
The lesson to be kept is nuanced: even without adopting the complete framework, maintaining the most useful isolated practices (automated tests, continuous integration, refactoring) remains profitable in almost all development missions.
Should you adopt Extreme Programming in your IT projects?
To adopt XP or not is first and foremost a margin arbitrage: what you invest in quality upstream, you save in takeover and technical debt downstream. The only question that matters for a service company remains: does it pay for you? The only way to know is to measure it. Track the actual time spent, the landing margin and the utilization rate per mission makes it possible to decide, mission by mission, whether the pair programming and Test Driven Design have reimbursed their additional cost. This is the role of a project management tool, which links the time spent to the margins without re-entry, and transforms an intuition into a substantiated decision.
Frequently asked questions:
An agile method of software development created by Kent Beck in the 1990s. It is based on five values and twelve engineering practices (pair programming, pre-code testing, continuous integration, refactoring) that aim for high quality and a high capacity to absorb changing needs.
No, they are two different but complementary things. Scrum organizes work (sprints, roles) without saying how to code; XP provides just these engineering practices. So you can practice XP inside a Scrum framework, it's even the most common combination.
Agile is a set of principles; Extreme Programming is an implementation that takes these principles to the extreme on a technical level. Where other methods remain at the organizational level, XP goes down to how to write and test code.
It costs more hours in the moment but reduces defects and spreads knowledge. Its interest depends on the context: very profitable on complex tasks and to bring up juniors, less so on simple tasks. It's not an automatic win everywhere.
Rarely in full framework, but its practices are everywhere: automated testing, continuous integration, refactoring and pair programming have become standards, even when teams no longer call them "XP". The arrival of AI code assistants has put pair programming back at the center of the debate.
On a pure audit or consulting mission (little code), a disposable or very short project, a distributed team without tools or with a high turnover. XP requires a small team, automatable testing and an involved customer; Without these conditions, the additional cost is not reimbursed.
The most structuring are pair programming, test-driven development, continuous integration, continuous refactoring, simple design, and frequent small deliveries. Many teams are already applying some of it without knowing it.
In the short term, yes: pair programming and testing add additional costs when it comes to scoping and defining tests. But this additional cost can be reimbursed, because it avoids costly mistakes downstream. At the flat rate, it is even what protects your margin on landing. It all depends on where this cost is paid.
In a sales department, invoicing two developers for a task is difficult to negotiate: reserve pair programming for parties at risk, or include it in a commitment to results. With a fixed price, the question does not arise, because you are selling a deliverable and not hours: pair programming remains a quality internal choice.
