extreme-programming

eXtreme Programming In A Nutshell

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

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.

Related Business Concepts

scaled-agile-lean-development
Scaled Agile Lean Development (ScALeD) helps businesses discover a balanced approach to agile transition and scaling questions. The ScALed approach helps businesses successfully respond to change. Inspired by a combination of lean and agile values, ScALed is practitioner-based and can be completed through various agile frameworks and practices.
test-driven-development
As the name suggests, TDD is a test-driven technique for delivering high-quality software rapidly and sustainably. It is an iterative approach based on the idea that a failing test should be written before any code for a feature or function is written. Test-Driven Development (TDD) is an approach to software development that relies on very short development cycles.
feature-driven-development
Feature-Driven Development is a pragmatic software process that is client and architecture-centric. Feature-Driven Development (FDD) is an agile software development model that organizes workflow according to which features need to be developed next.
extreme-programming
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.
dual-track-agile
Product discovery is a critical part of agile methodologies, as its aim is to ensure that products customers love are built. Product discovery involves learning through a raft of methods, including design thinking, lean start-up, and A/B testing to name a few. Dual Track Agile is an agile methodology containing two separate tracks: the “discovery” track and the “delivery” track.
timeboxing
Timeboxing is a simple yet powerful time-management technique for improving productivity. Timeboxing describes the process of proactively scheduling a block of time to spend on a task in the future. It was first described by author James Martin in a book about agile software development.
rapid-application-development
RAD was first introduced by author and consultant James Martin in 1991. Martin recognized and then took advantage of the endless malleability of software in designing development models. Rapid Application Development (RAD) is a methodology focusing on delivering rapidly through continuous feedback and frequent iterations.
mvc-framework
The MVC framework is a predictable software design pattern separated into three main components and suitable for many programming languages. The goal of the MVC framework is to help structure the code-base and separate application concerns into three components: View, Model, and Controller.
agile-methodology
Agile started as a lightweight development method compared to heavyweight software development, which is the core paradigm of the previous decades of software development. By 2001 the Manifesto for Agile Software Development was born as a set of principles that defined the new paradigm for software development as a continuous iteration. This would also influence the way of doing business.
devsecops
DevSecOps is a set of disciplines combining development, security, and operations. It is a philosophy that helps software development businesses deliver innovative products quickly without sacrificing security. This allows potential security issues to be identified during the development process – and not after the product has been released in line with the emergence of continuous software development practices.

Read Next: Business AnalysisCompetitor Analysis, Continuous InnovationAgile MethodologyLean StartupBusiness Model InnovationProject Management.

Main Free Guides:

Scroll to Top
FourWeekMBA
[class^="wpforms-"]
[class^="wpforms-"]