eXtreme Programming was developed in the late 1990s by Ken Beck, Ron Jeffries, and Ward Cunningham. During this time, the trio was working on the Chrysler Comprehensive Compensation System (C3) to help manage the company payroll system. eXtreme Programming (XP) is a software development methodology. It is designed to improve software quality and the ability of software to adapt to changing customer needs.
Understanding eXtreme Programming
In 1999, they published the book Extreme Programming Explained about their collective experience at Daimler Chrysler and described their methods in detail.
From their experiences, XP was born.
Extreme Programming is like many other agile methods, but in an interview, Beck explained what makes XP unique:
“The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.”
Indeed, XP promotes frequent, iterative releases throughout the software development life cycle (SDLC).
But the main difference between XP and similar methods, as Beck notes, is that it takes software engineering to “extreme” levels.
Code reviews are one such example. In XP, pair programming should be subject to peer reviews 100% of the time.
XP also focuses on short iterations and release cycles. This helps businesses reduce the likelihood of misalignment with customer needs caused by unnecessary product features.
When should eXtreme Programming be used?
XP is best suited to businesses that can incorporate a high degree of customer collaboration and continuous development.
Having said that, XP can also work well for teams that:
- Expect system functionality to change periodically, such as every few months.
- Have tight deadlines and want to mitigate risk.
- Have a small number of programmers who contribute to code and suggest fixes, etc. By using pair programming and frequently rotating programmers through the team, XP facilities communication and collaboration.
- Deal with customers who constantly change project requirements because of uncertainty around what they want the system to achieve. In this case, teams can use class-responsibility-collaboration (CRC) cards that allow them to design a system and see how each object interacts.
The five fundamental values of eXtreme Programming
Early incarnations of eXtreme Programming established five fundamental values that are now common to many subsequent frameworks such as Scrum.
The five values are:
Simplicity
To maximize value, the project team will do what is needed – but no more.
Product development should be broken down into small, value-adding steps that identify and then mitigate errors as they occur.
Streamlined communication
Teams work together on every facet of a project and participate in daily face-to-face meetings so that every member is abreast of the latest developments.
Individuals are encouraged to raise any concerns which should be addressed swiftly.
Consistent, constructive feedback
eXtreme Programming teams adapt their processes to the needs of the project and the customer.
The software should be demonstrated early on so that feedback can guide necessary improvements.
Respect
Each team member should give and receive respect.
This can be facilitated by ensuring that everyone feels they are making a positive contribution – no matter how trivial or insignificant.
Developers should respect the expertise and knowledge of customers, and vice versa.
Respect also means that management let project teams work with autonomy and responsibility without becoming dictatorial.
Courage
This can be difficult because it often necessitates that hard decisions be made.
Courage also involves telling the truth about progress, particularly when progress has not met expectations.
To that end, no excuses for failure are ever made.
eXtreme programming Vs. Scrum

Scrum is a broader methodology and toolbox, which can also comprise eXtreme programming as one of the tools within that toolbox.
eXtreme programming Vs. Agile

eXtreme programming is a sort of agile methodology as, like in agile, it supports frequent releases in very short cycles by focusing on simplicity, streamlined communication, consistent feedback, respect, and courage.
Yet, compared to agile in general, where there is a loop and a small layer between the development teams and customers, intermediate by product managers, which cross the bridge between developers and customers.
In eXtreme programming, the customer is part of the loop, and there are – in theory – no layers between the development team and customers, which are active participants n these short development cycles.
eXtreme programming Vs. Kanban

Whereas Kanban, as adapted in software development, does not necessarily follow an interactive cycle, eXtreme programming, similarly to other agile methodologies and Scrum, does follow an iterative cycle.
Key takeaways
- eXtreme Programming is an agile methodology that supports frequent releases in very short cycles. This allows developers to adapt to changing customer requirements without sacrificing quality.
- eXtreme Programming is best suited to smaller project teams who can continuously engage with customers to a high degree.
- eXtreme Programming is based on five fundamental values: simplicity, streamlined communication, consistent feedback, respect, and courage. Many of these values have been adopted for use in subsequent agile methodologies.
Connected Agile Frameworks





































Read: Innovation, Agile Methodology, Lean Startup, Business Model
Read about other product development frameworks here.
Read Next: Business Analysis, Competitor Analysis, Continuous Innovation, Agile Methodology, Lean Startup, Business Model Innovation, Project Management.
Main Free Guides: