EXTREME PROGRAMMING (XP)

Extreme programming (XP) is an important process model under the agile umbrella and was
proposed by Kent Beck in 1999. The name of this model reflects the fact that it recommends
taking these best practices that have worked well in the past in program development projects
to extreme levels. This model is based on a rather simple philosophy:” If something is known
to be beneficial, why not put it to constant use?” Based on this principle, it puts forward
several key practices that need to be practised to the extreme.
Extreme Programming (XP), the most widely used approach to agile software development,
emphasizes business results first and takes an incremental, get-something-started
approach to building the product, using continual testing and revision.

 XP Values
Beck defines a set of five values that establish a foundation for all work performed as part of
XP—communication, simplicity, feedback, courage, and respect. Each of these values is
used as a driver for specific XP activities, actions, and tasks.
In order to achieve effective communication between software engineers and other
stakeholders, XP emphasizes close, yet informal collaboration between customers and
developers, the establishment of effective metaphors for communicating important concepts,
continuous feedback, and the avoidance of voluminous documentation as a communication
medium.
To achieve simplicity, XP restricts developers to design only for immediate needs, rather than
consider future needs. The intent is to create a simple design that can be easily implemented
in code. If the design must be improved, it can be refactored at a later time.
Feedback is derived from three sources: the implemented software itself, the customer, and
other software team members. By designing and implementing an effective testing strategy
the software provides the agile team with feedback. XP makes use of the unit test as its
primary testing tactic. As each class is developed, the team develops a unit test to exercise
each operation according to its specified functionality.
Beck argues that strict adherence to certain XP practices demands courage. A better word
might be discipline. An agile XP team must have the discipline (courage) to design for today,
recognizing that future requirements may change dramatically, thereby demanding substantial
rework of the design and implemented code.
By following each of these values, the agile team inculcates respect among its members,
between other stakeholders and team members, and indirectly, for the software itself. As they
achieve successful delivery of software increments, the team develops growing respect for
the XP process.

 The XP Process
Extreme Programming uses an object-oriented approach as its preferred development
paradigm and encompasses a set of rules and practices that occur within the context of four
framework activities: planning, design, coding, and testing. Following figure illustrates the
XP process and notes some of the key ideas and tasks that are associated with each
framework activity.
Key XP activities are
 Planning: The planning activity (also called the planning game) begins with listening—a
requirements gathering activity that enables the technical members of the XP team to
understand the business context for the software and to get a broad feel for required output
and major features and functionality.

Listening leads to the creation of a set of “stories” (also called user stories) that describe
required output, features, and functionality for software to be built. Each story is written
by the customer and is placed on an index card. The customer assigns a value (i.e., a
priority) to the story based on the overall business value of the feature or function.
Members of the XP team then assess each story and assign a cost —measured in
development weeks—to it. If the story is estimated to require more than three
development weeks, the customer is asked to split the story into smaller stories and
the assignment of value and cost occurs again. It is important to note that new stories can
be written at any time.

Customers and developers work together to decide how to group stories into the next
release (the next software increment) to be developed by the XP team. Once a basic
commitment (agreement on stories to be included, delivery date, and other project
matters) is made for a release, the XP team orders the stories that will be developed in
one of three ways: (1) all stories will be implemented immediately (within a few weeks),
(2) the stories with highest value will be moved up in the schedule and implemented first,
or (3) the riskiest stories will be moved up in the schedule and implemented first.

After the first project release (also called a software increment) has been delivered, the XP
team computes project velocity. Stated simply, project velocity is the number of customer
stories implemented during the first release. Project velocity can then be used to (1) help
estimate delivery dates and schedule for subsequent releases and (2) determine whether an
over commitment has been made for all stories across the entire development project. If an
over commitment occurs, the content of releases is modified or end delivery dates are
changed.

As development work proceeds, the customer can add stories, change the value of an
existing story, split stories, or eliminate them. The XP team then reconsiders all remaining
releases and modifies its plans accordingly.
 Design: XP design rigorously follows the KIS (keep it simple) principle. A simple
design is always preferred over a more complex representation. In addition, the design
provides implementation guidance for a story as it is written—nothing less, nothing more.
The design of extra functionality (because the developer assumes it will be required later)
is discouraged. If a difficult design problem is encountered as part of the design of a
story, XP recommends the immediate creation of an operational prototype of that
portion of the design. Called a spike solution, the design prototype is implemented and
evaluated. XP encourages refactoring—a construction technique that is also a method for
design optimization.

Fowler describes refactoring in the following manner: Refactoring is the process of

changing a software system in such a way that it does not alter the external behaviour of
the code yet improves the internal structure. It is a disciplined way to clean up code [that
minimizes the chances of introducing bugs].

 Coding: After stories are developed and preliminary design work is done, the team does
not move to code, but rather develops a series of unit tests that will exercise each of the
stories that is to be included in the current release. Once the unit test has been created,
the developer is better able to focus on what must be implemented to pass the test. Nothing
extraneous is added. Once the code is complete, it can be unit-tested immediately, thereby
providing instantaneous feedback to the developers.

A key concept during the coding activity is pair programming. XP recommends that two
people work together at one computer workstation to create code for a story. This provides
a mechanism for real time problem solving (two heads are often better than one) and
real-time quality assurance. It also keeps the developers focused on the problem at hand.
In practice, each person takes on a slightly different role. For example, one person might
think about the coding details of a particular portion of the design while the other ensures
that coding standards (a required part of XP) are being followed or that the code for the
story will satisfy the unit test that has been developed to validate the code against the
story.

As pair programmers complete their work, the code they develop is integrated with the
work of others. In some cases, this is performed on a daily basis by an integration team. In
other cases, the pair programmers have integration responsibility. This “continuous
integration” strategy helps to avoid compatibility and interfacing problems and
provides a “smoke testing” environment that helps to uncover errors early.

 Testing: The creation of unit tests before coding commences is a key element of the XP
approach. The unit tests that are created should be implemented using a framework that
enables them to be automated. This encourages a regression testing strategy whenever
code is modified. As the individual unit tests are organized into a “universal testing suite”
integration and validation testing of the system can occur on a daily basis. This provides
the XP team with a continual indication of progress and also can raise warning flags early
if things go awry. Wells states: “Fixing small problems every few hours takes less time
than fixing huge problems just before the deadline.”

XP acceptance tests, also called customer tests, are specified by the customer and focus
on overall system features and functionality that are visible and reviewable by the
customer. Acceptance tests are derived from user stories that have been implemented as
part of a software release.
 Applicability of Extreme Programming Model
The following are some of the project characteristics that indicate the suitability of a project
for development using extreme programming model:
Projects involving new technology or research projects: In this case, the requirements
change rapidly and unforeseen technical problems need to be resolved.
Small projects: Extreme programming was proposed in the context of small teams as face to
face meeting is easier to achieve.

 Project characteristics not suited to development using agile models

The following are some of the project characteristics that indicate unsuitability of agile
development model for use in a development project:
Stable requirements: Conventional development models are more suited to use in projects
characterised by stable requirements. For such projects, it is known that few changes, if at all,
will occur. Therefore, process models such as iterative waterfall model that involve making
long-term plans during project initiation can meaningfully be used.
Mission critical or safety critical systems: In the development of such systems, the
traditional SDLC models are usually preferred to ensure reliability.
 Industrial XP
Joshua Kerievsky describes Industrial Extreme Programming (IXP) in the following manner:
“IXP is an organic evolution of XP. It is imbued with XP’s minimalist, customer-centric,
test- driven spirit. IXP differs most from the original XP in its greater inclusion of
management, its expanded role for customers, and its upgraded technical practices.”
IXP incorporates six new practices that are designed to help ensure that an XP project works
successfully for significant projects within a large organization.
 Readiness assessment: Prior to the initiation of an IXP project, the organization should
conduct a readiness assessment. The assessment ascertains whether (1) an appropriate
development environment exists to support IXP, (2) the team will be populated by the
proper set of stakeholders, (3) the organization has a distinct quality program and supports
continuous improvement, (4) the organizational culture will support the new values of an
agile team, and (5) the broader project community will be populated appropriately.

 Project community: The IXP team determines whether the right people, with the right
skills and training have been staged for the project. The “community” encompasses
technologists and other stakeholders. Classic XP suggests that the right people be used to
populate the agile team to ensure success. The implication is that people on the team must
be well- trained, adaptable and skilled, and have the proper temperament to contribute to
a self- organizing team. When XP is to be applied for a significant project in a large
organization, the concept of the “team” should morph into that of a community. A
community may have a technologist and customers who are central to the success of a
project as well as many other stakeholders (e.g., legal staff, quality auditors, manufacturing
or sales types) who “are often at the periphery of an IXP project yet they may play
important roles on the project”. In IXP, the community members and their roles should be
explicitly defined and mechanisms for communication and coordination between
community members should be established.

 Project chartering: The IXP team assesses the project itself to determine whether an
appropriate business justification for the project exists and whether the project will
further the overall goals and objectives of the organization. Chartering also examines
the context of the project to determine how it complements, extends, or replaces existing
systems or processes.

 Test-driven management: An IXP project requires measurable criteria for assessing the
state of the project and the progress that has been made to date. Test-driven management
establishes a series of measurable “destinations” and then defines mechanisms for
determining whether or not these destinations have been reached.

 Retrospectives: An IXP team conducts a specialized technical review after a software

increment is delivered. Called a retrospective, the review examines “issues, events, and
lessons-learned” across a software increment and/or the entire software release. The intent
is to improve the IXP process.

 Continuous learning: Because learning is a vital part of continuous process improvement,

members of the XP team are encouraged (and possibly, incented) to learn new methods
and techniques that can lead to a higher quality product.
 Scrum
Scrum is an agile software development method that was conceived by Jeff Sutherland and
his development team in the early 1990s. Scrum principles are consistent with the agile
manifesto and are used to guide development activities within a process that incorporates the
following framework activities: requirements, analysis, design, evolution, and delivery.
Within each framework activity, work tasks occur within a process pattern called a sprint.
The work conducted within a sprint is adapted to the problem at hand and is defined and
often modified in real time by the Scrum team. The overall flow of the Scrum process is
illustrated in following figure

Scrum emphasizes the use of a set of software process patterns that have proven effective
for projects with tight timelines, changing requirements, and business criticality. Each of
these process patterns defines a set of development actions:
 Backlog—a prioritized list of project requirements or features that provide business
value for the customer. Items can be added to the backlog at any time. The product
manager assesses the backlog and updates priorities as required.
 Sprints—consist of work units that are required to achieve a requirement defined in the
backlog that must be fit into a predefined time-box (typically 30 days). Changes (e.g.,
backlog work items) are not introduced during the sprint. Hence, the sprint allows team
members to work in a short-term, but stable environment.
 Scrum meetings—are short (typically 15 minutes) meetings held daily by the Scrum
team. Three key questions are asked and answered by all team members
 What did you do since the last team meeting?
 What obstacles are you encountering?
 What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and assesses the responses from
each person. The Scrum meeting helps the team to uncover potential problems as early as
possible. Also, these daily meetings lead to “knowledge socialization”
 Demos—deliver the software increment to the customer so that functionality that has
been implemented can be demonstrated and evaluated by the customer. It is important
to note that the demo may not contain all planned functionality, but rather those functions
that can be delivered within the time-box that was established.