INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

XP Lifecycle, The XP Team, XP Concepts: Refactoring, Technical Debt, Timeboxing,

Stories, Velocity; Adopting XP: Pre-requisites, Challenges; Applying XP: Thinking- Pair
Programming, Collaborating, Release, Planning, Development; XP Case Study.

Introduction to Extreme Programming:

What is Extreme Programming?

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop a
software.

eXtreme Programming (XP) was conceived and developed to address the specific needs of
software development by small teams in the face of vague and changing requirements.

Extreme Programming is one of the Agile software development methodologies. It provides

values and principles to guide the team behavior. The team is expected to self-organize. Extreme
Programming provides specific core practices where −

• Each practice is simple and self-complete.

• Combination of practices produces more complex and emergent behavior.

Embrace Change

A key assumption of Extreme Programming is that the cost of changing a program can be held
mostly constant over time.

This can be achieved with −

• Emphasis on continuous feedback from the customer

• Short iterations
• Design and redesign
• Coding and testing frequently
• Eliminating defects early, thus reducing costs
• Keeping the customer involved throughout the development
• Delivering working product to the customer
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Extreme Programming involves −

• Writing unit tests before programming and keeping all of the tests running at all times.
The unit tests are automated and eliminates defects early, thus reducing the costs.
• Starting with a simple design just enough to code the features at hand and redesigning
when required.
• Programming in pairs (called pair programming), with two programmers at one screen,
taking turns to use the keyboard. While one of them is at the keyboard, the other
constantly reviews and provides inputs.
• Integrating and testing the whole system several times a day.
• Putting a minimal working system into the production quickly and upgrading it whenever
required.
• Keeping the customer involved all the time and obtaining constant feedback.

Iterating facilitates the accommodating changes as the software evolves with the changing
requirements.

Why is it called “Extreme?”

Extreme Programming takes the effective principles and practices to extreme levels.

• Code reviews are effective as the code is reviewed all the time.
• Testing is effective as there is continuous regression and testing.
• Design is effective as everybody needs to do refactoring daily.
• Integration testing is important as integrate and test several times a day.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

• Short iterations are effective as the planning game for release planning and iteration
planning.

History of Extreme Programming

Kent Beck, Ward Cunningham and Ron Jeffries formulated extreme Programming in 1999. The
other contributors are Robert Martin and Martin Fowler.

In Mid-80s, Kent Beck and Ward Cunningham initiated Pair Programming at Tektronix. In the
80s and 90s, Smalltalk Culture produced Refactoring, Continuous Integration, constant testing,
and close customer involvement. This culture was later generalized to the other environments.

In the Early 90s, Core Values were developed within the Patterns Community, Hillside Group. In
1995, Kent summarized these in Smalltalk Best Practices, and in 1996, Ward summarized it in
episodes.

In 1996, Kent added unit testing and metaphor at Hewitt. In 1996, Kent had taken the Chrysler
C3 project, to which Ron Jeffries was added as a coach. The practices were refined on C3 and
published on Wiki.

Scrum practices were incorporated and adapted as the planning game. In 1999, Kent published
his book, ‘Extreme Programming Explained’. In the same year, Fowler published his book,
Refactoring.

Extreme Programming has been evolving since then, and the evolution continues through today.

Success in Industry
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

The success of projects, which follow Extreme Programming practices, is due to −

• Rapid development.
• Immediate responsiveness to the customer’s changing requirements.
• Focus on low defect rates.
• System returning constant and consistent value to the customer.
• High customer satisfaction.
• Reduced costs.
• Team cohesion and employee satisfaction.

Extreme Programming Advantages

Extreme Programming solves the following problems often faced in the software development
projects −

• Slipped schedules − and achievable development cycles ensure timely deliveries.

• Cancelled projects − Focus on continuous customer involvement ensures transparency
with the customer and immediate resolution of any issues.
• Costs incurred in changes − Extensive and ongoing testing makes sure the changes do
not break the existing functionality. A running working system always ensures sufficient
time for accommodating changes such that the current operations are not affected.
• Production and post-delivery defects: Emphasis is on − the unit tests to detect and fix
the defects early.
• Misunderstanding the business and/or domain − Making the customer a part of the
team ensures constant communication and clarifications.
• Business changes − Changes are considered to be inevitable and are accommodated at
any point of time.
• Staff turnover − Intensive team collaboration ensures enthusiasm and good will.
Cohesion of multi-disciplines fosters the team spirit.

XP Lifecycle:
With software engineering existing in such a fast-paced environment, traditional
project management approaches are no longer viable. That means that IT
professionals must find new ways to handle frequently changing development tasks.

Sharing this idea and focusing on the existing incremental development techniques, 17
software specialists introduced the Agile project management philosophy in 2001.
Principles of flexible, fast, and collaboration-centered software development were
outlined in the Agile Manifesto.

Extreme Programming (XP) is one of the numerous Agile frameworks applied by IT

companies. But its key feature — emphasis on technical aspects of software
development — distinguishes XP from the other approaches.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Software engineer Ken Beck introduced XP in the 90s with the goal of finding ways
to write high-qualitative software quickly and being able to adapt to customers’
changing requirements. In 1999, he refined XP approaches in the book Extreme
Programming Explained: Embrace Change.

XP is a set of engineering practices. Developers have to go beyond their capabilities

while performing these practices. That’s where the "extreme" in the framework’s title
comes from. To get a better understanding of these practices, we’ll start with
describing XP’s lifecycle and the roles engaged in the process.

The process and roles of extreme programming:

The XP framework normally involves 5 phases or stages of the development process

that iterate continuously:
1. Planning, the first stage, is when the customer meets the development team and
presents the requirements in the form of user stories to describe the desired result. The
team then estimates the stories and creates a release plan broken down into iterations
needed to cover the required functionality part after part. If one or more of the stories
can’t be estimated, so-called spikes can be introduced which means that further
research is needed.
2. Designing is actually a part of the planning process, but can be set apart to emphasize
its importance. It’s related to one of the main XP values that we’ll discuss below --
simplicity. A good design brings logic and structure to the system and allows to avoid
unnecessary complexities and redundancies.
3. Coding is the phase during which the actual code is created by implementing specific
XP practices such as coding standards, pair programming, continuous integration, and
collective code ownership (the entire list is described below).
4. Testing is the core of extreme programming. It is the regular activity that involves
both unit tests (automated testing to determine if the developed feature works
properly) and acceptance tests (customer testing to verify that the overall system is
created according to the initial requirements).
5. Listening is all about constant communication and feedback. The customers and
project managers are involved to describe the business logic and value that is
expected.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Such a development process entails the cooperation between several participants, each
having his or her own tasks and responsibilities. Extreme programming puts people in
the center of the system, emphasizing the value and importance of such social skills as
communication, cooperation, responsiveness, and feedback. So, these roles are
commonly associated with XP:
1. Customers are expected to be heavily engaged in the development process by
creating user stories, providing continuous feedback, and making all the necessary
business decisions related to the project.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

2. Programmers or developers are the team members that actually create the product.
They are responsible for implementing user stories and conducting user tests
(sometimes a separate Tester role is set apart). Since XP is usually associated
with cross-functional teams, the skill set of such members can be different.
3. Trackers or managers link customers and developers. It’s not a required role and can
be performed by one of the developers. These people organize the meetups, regulate
discussions, and keep track of important progress KPIs.
4. Coaches can be included in the teams as mentors to help with understanding the XP
practices. It’s usually an outside assistant or external consultant who is not involved in
the development process, but has used XP before and so can help avoid mistakes.

The XP Team

When we speak about various Agile methodologies, we see that there are only two things that
make them different methods. The first thing is the type and length of iterative cycles. In some
methodologies it is longer, in others – shorter. The second thing is the structure of the team. Each
Agile methodology has its own approach to team management. In this article we will tell you
about the Extreme Programming team.
Like in other agile methodologies, in XP you may not find all usual software development roles.
Extreme programming teams are small. Sometimes they are even single person teams. However,
they are able to perform the hardest software development industry tasks. That is because of the
fact that Extreme Programming is a methodology that was designed especially for delivering
the largest amounts of production within the shortest amounts of time. If an XP developer works
on a project alone, he can use an Extreme Programming team foundation server. There he can
find other XP specialists and cooperate with them. Such service is especially popular among
freelancers. However, large software development companies also use them to find employees
for their new projects.
Despite the fact that even one person can create an XP team; specialists usually define
seven Extreme Programming team roles. Let’s look at them in greater detail.

1. Programmer

His responsibility is to estimate user stories and separate them from technical tasks. He is also
responsible for estimating the time required to finish the project.

2. Tester

This employee is responsible for conducting functional tests and informing the team on their
results.

3. Tracker
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

This person’s main task is to interview the developers every week and find out if something in
their work goes wrong.

4. Customer

The customer is the main person in XP. He is the one who writes user stories and estimates the
final and intermediate product.

5. Coach

His main responsibility is to keep the project extreme. He teaches other team members how to
achieve this goal.

6. Manager

A very important role in every Extreme Programming team. This person is responsible for
conducting team meetings and making them effective.

7. Doomsayer

This role is also extremely important, because this person’s main task is to follow the progress of
the project and avoid problems in its realization, like not meeting the terms, or other failures.

XP (Extreme Programming) concepts:

1. Refactoring

Refactoring is the process of restructuring existing code without changing its external behavior.
It improves the internal structure of the software, making it more maintainable, readable, and
adaptable to future changes. Refactoring is a core practice in Extreme Programming (XP) and
Agile methodologies, as it helps keep the codebase clean and reduces complexity over time.

Examples:

• Removing duplicate code

• Breaking large methods into smaller, more manageable ones
• Improving variable and function names
• Reorganizing classes and methods

Benefits:

• Easier to understand and maintain the code

• Facilitates faster debugging and feature additions
• Helps prevent technical debt (see below)
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

2. Technical Debt

Technical debt refers to the long-term cost and complications that arise from choosing quick,
short-term solutions over more robust but time-consuming approaches. It is often the result of
rushed development, lack of refactoring, or postponed maintenance activities. Technical debt can
accumulate and lead to more bugs, slower development, and high maintenance costs.

Types of Technical Debt:

• Deliberate: A known compromise is made for quick delivery, with the intention of fixing
it later.
• Accidental: Results from poor coding practices or lack of experience.
• Bit Rot: Accumulates over time as systems become outdated or less aligned with
evolving requirements.

Mitigating Technical Debt:

• Regular refactoring
• Ensuring good coding standards
• Allocating time for technical improvements during iterations

3. Timeboxing

Timeboxing is the practice of setting a fixed amount of time for an activity, ensuring that tasks
do not extend indefinitely. The focus is on completing the work within the allocated time, even if
some functionality might need to be deferred to later. Timeboxing encourages focus, avoids
scope creep, and helps teams meet deadlines more consistently.

Applications:

• Iterations or sprints in Agile development are timeboxed (e.g., 1-2 weeks).

• Meetings, design discussions, or coding tasks can be timeboxed to avoid wasting time.

Benefits:

• Promotes productivity by reducing the tendency to overthink or over-engineer solutions.

• Encourages frequent delivery and progress tracking.

4. Stories (User Stories)

User stories are short, simple descriptions of a feature or functionality from the perspective of the
end user. They are a common method for capturing requirements in XP and Agile. User stories
typically follow a simple format: "As a [type of user], I want [some goal], so that [some
reason/benefit]."
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Example:
"As a customer, I want to be able to reset my password so that I can regain access if I forget it."

Key Elements:

• User: The role or persona.

• Goal: The functionality or feature desired.
• Reason: The benefit or value provided.

Benefits:

• Keeps development user-centered.

• Ensures clear communication between developers and stakeholders.
• Stories are small, manageable units of work that can be estimated and prioritized easily.

5. Velocity

Velocity is a measure of how much work a team can complete in a given iteration, usually
measured in terms of story points, hours, or completed tasks. It reflects the team's capacity and
helps in planning future iterations by estimating how much work can be taken up.

Calculation:
Velocity is calculated by summing up the story points of all completed user stories in an
iteration.

Benefits:

• Provides a clear measure of team performance.

• Helps in predicting delivery timelines and future workload capacity.
• Teams can improve velocity by enhancing processes, collaborating better, or reducing
technical debt.

Improving Velocity:

• Prioritize and complete smaller, manageable stories.

• Ensure stories are well-defined and understood by the team.
• Continuous improvement through retrospective meetings.

These concepts are central to XP and Agile methodologies, emphasizing iterative development,
continuous improvement, and maintaining high-quality code through disciplined practices.

Adopting XP: Pre-requisites, Challenges

Adopting Extreme Programming (XP) can significantly improve software development
processes, but it comes with its own set of prerequisites and challenges. Here’s a breakdown:
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Prerequisites

1. Team Commitment: All team members must be committed to XP practices and values. This
includes developers, testers, and stakeholders.

2. Management Support: Leadership must support the adoption of XP, providing the necessary
resources and encouraging a culture of collaboration and experimentation.

3. Customer Involvement: Continuous feedback from customers or product owners is essential

for XP. Having a dedicated representative available to provide feedback and prioritize features is
crucial.

4. Cohesive Team: A stable and small team (ideally 5-10 members) that can work closely
together is vital for effective communication and collaboration.

5. Knowledge of Agile Principles: A basic understanding of Agile methodologies can help ease
the transition to XP.

6. Development Environment: A conducive development environment that supports continuous

integration, automated testing, and version control is necessary.

Challenges

1. Cultural Resistance: Teams accustomed to traditional development methodologies may resist

the drastic changes that XP requires, such as pair programming and continuous feedback.

2. Skill Gaps: Not all team members may have experience with XP practices, leading to a steep
learning curve. Training and mentoring may be needed.

3. Customer Availability: Maintaining consistent customer involvement can be challenging,

especially if stakeholders have limited availability.

4. Integration with Existing Processes: Integrating XP with existing organizational processes can
lead to conflicts, especially if the organization is not fully Agile.

5. Misunderstanding of Practices: Misinterpretation of XP practices can lead to ineffective

implementations. Proper training and guidance are essential.

6. Short-term Focus: Teams may struggle to focus on long-term goals while delivering frequent
releases, which can affect project direction and vision.

7. Tooling: Choosing the right tools for continuous integration, testing, and collaboration can be
daunting, and inadequate tools can hinder the XP process.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Thus Successfully adopting XP requires careful planning, strong leadership, and a willingness to
embrace change. Addressing prerequisites and anticipating challenges can lead to a smoother
transition and ultimately enhance the quality and efficiency of software development.

Applying XP: Thinking- Pair Programming, Collaborating, Release,

Planning, Development

Pair programming is an Agile software development technique originating from

Extreme programming (XP) in which two developers team together on one computer.
The two people work together to design, code and test user stories. Ideally, the two
people would be equally skilled and would each have equal time at the keyboard.

A common implementation of pair programming calls the programmer at the

keyboard the driver, while the other is called the navigator. The navigator focuses on
the overall direction of the programming. The collaboration between developers can
be done in person or remotely.

Pair programming is a collaborative effort that involves a lot of communication. The

idea is to have the driver and navigator communicate, discuss approaches and solve
issues that might be difficult for a single developer to detect.

This Agile software development technique is not well suited for everyone, however.
Learning to partner effectively in a team that close and share a work computer takes
skills that not all programmers possess. It requires both programmers to have the soft
skills required for collaboration, as well as the requisite hard skills to write and test
code. Some businesses may adopt the practice, while others may opt not to use it.

How does pair programming work?

Pair programming requires two developers, one workstation, one keyboard and a
mouse. The pairings can be assigned or self-assigned.

Pair programming uses the four eyes principle, which ensures two sets of eyes review
the code that is being produced, even when there is a division of labor. While the
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

driver writes the code, the navigator checks the code being written. The driver focuses
on the specifics of coding, while the navigator checks the work, code quality and
provides direction.

The process starts with the developers receiving a well-defined task. They agree on
one small goal at a time, such as writing code, testing or just taking notes. Any
discussions on direction or corrections can be made after each goal, as to avoid
interrupting the driver's flow. The two programmers can talk about the various
techniques and challenges, with the results usually being higher quality code than
when one person does the same work.

The two developers take turns coding or reviewing and check each other's work as
they go. Rotating roles regularly helps keep both developers alert and engaged.
Organizations may also have the pair rotate roles to work on different tasks. This way,
they get experience working on the different parts of the system being built.

Depending on how the pairs are coordinated, junior and senior developers can work
together, enabling senior developers to share their knowledge and working habits. It
also helps new team members get up to speed on a project.

Benefits of pair programming

Pair programming includes the following advantages:

• Fewer coding mistakes. Another programmer is looking over the driver's code,
which can help reduce mistakes and improve the quality of the code.

• Knowledge is spread among the pairs. Junior developers can pick up more skills
from senior developers. And those unfamiliar with a process can be paired with
someone who knows more about the process.

• Reduced effort to coordinate. Developers will get used to collaborating and

coordinating their efforts.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

• Increased resiliency. Pair programming helps developers understand each part of

a codebase, meaning the environment will not be dependent on a single person for
repairs if something breaks.
Challenges of pair programming
Pair programming includes the following pitfalls:

• Efficiency. Common logic might dictate that pair programming would reduce
productivity by 50%, because two developers are working on the same project at
one time. According to a blog post on Raygun, pairs work about 15% slower,
which is an improvement but is still less than the productivity of two separate
programmers.

• Equally engaging pairs. If both developers do not equally engage in the project,
then there is less chance that knowledge will be shared, and it is highly probable
that one developer will participate less than the other.

• Social and interactive process. It is hard for those who work better alone. Pairs
that have trouble together might be better suited to work by themselves; forcing
them to collaborate may hurt their work ethic.

• Sustainability. The pace may not be suited to practicing hours at a time. Likely,
developers will need breaks at different times.
Pair programming styles and techniques
Pair programming uses three general programming styles: the driver/navigator style,
unstructured style and ping-pong style.

Driver/navigator style. The driver/navigator approach is a popular pair programming

style where one programmer handles the mechanical side like coding, and the other is
in control of the strategic or architectural elements like reviewing code. The driver
and navigator switch roles often. This style works well for a novice paired with an
expert programmer. The navigator role can range from a reserved approach to a
tactical hands-on role.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Unstructured style. Most pair programming relationships fall into the unstructured
style, where two programmers work together in an Ad hoc manner and collaboration
is loosely guided. Both programmers should have matching skill levels. A common
variant of this style is the unstructured expert-novice pair, where an expert
programmer and a novice are paired together.

An unstructured approach is difficult to discipline and unlikely to last for longer

projects. Unstructured pair programming is also harder to keep afloat remotely. This
approach is considered if programmers do not know what will work best for a project
upfront.

Ping-pong style. With the ping-pong approach, one developer writes a test and the
other developer makes the test pass. Each person alternates between writing and
passing tests. When two developers shift roles regularly, it is unlikely one
programmer will control the workflow. This style of pair programming is normally
performed in conjunction with test-driven development.

Three different pair programming styles.

Development teams should also choose pair programming styles that align with the
skills of the programmers involved. Potential skill pairs include:
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Expert/expert pairs. Two experts can generally work within any pair programming
style. Advanced programmers may prefer the ping-pong style, as it allows them to
have even participation.

Novice/novice pairs. Two novices together may have difficulty in the

driver/navigator style, because no one is experienced enough to take charge. In
addition, the unstructured approach may be difficult for beginner programmers.

Expert/novice pairs. The most common skill combination is an expert programmer

working with a less experienced person. Experts rely on their depth of knowledge to
direct the activity, while the novice can learn more from the expert.

Best practices for pair programming

Some best practices to follow when enacting pair programming include:

• Consistent communication. If there is no communication going on, then the

developers are likely not sharing thought processes.

• Switch roles consistently. This promotes the sharing of more skills between
developers and keeps them engaged.

• Pair up carefully. Ensure the two developers will be able to work together well,
without any hiccups. Otherwise, this will make for a poor work environment.

• Use a familiar development environment. Both developers should be familiar

with the environment they are working in. Otherwise, the balance of pair
programming will be disrupted.

• Submit code frequently. Quick commits to code pair well with switching
between the driver and the navigator.

• Ask for clarification when needed. Particularly when a novice works with an
expert, the novice should take any opportunity to learn.

• Take breaks when needed. Work at a pace that fits both developers.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Emergence of remote pair programming

Remote pair programming developers work together using a variety of tools, such as a
collaborative real-time editor, shared desktops or a remote pair programming
integrated development environment (IDE) plugin. Remote pairing can introduce
complexities such as extra delays in coordination, a potential loss in communication
and an increased reliance on task-tracking tools.

Collaborative coding tools include two pieces of technology: a communications

channel and an IDE. The collaborative communications tool can be a real-time audio
or video tool, such as a Microsoft Teams video call or Zoom. The collaborative IDE
tool enables the programming pair to share access to code and make references, such
as with Microsoft Visual Studio and CodeSandbox with its Live feature.

Developer pairs should schedule meetings each week for the same day and time in
order to establish the objectives of each pair programming session before it starts. If a
team is just moving to remote pair programming, then extra time should be allocated
to work out any kinks and try different styles.

Case Studies for Extreme Programming Practices (XP)

XP for Krizp System
The Problem
Krizp Solution was a startup, web-based development company in India. Their
business plan encompassed the creation of web portals for other small companies or
educational institutions. The company began as a part-time business, employing
people that were already working for other major IT organizations. The plan was to
continue full-time only if the startup ventured into success. There was no framework
for their software development processes as it was just a startup company with not
many projects and a few employees.

The company lacked a structured approach to software development. With initial

requirements jotted down on paper, further information and clarifications were
received from the customer via phone calls. Usually, the major changes in
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

requirements did not come about until the customer review, which was after the
solution was developed.

Other than for bug fixing, the developers had little or no communication with each
other. They worked separately on different features. This led to becoming a barrier to
discussions regarding improvement in working methods.

Moreover, the projects were not documented. There was no project manager to track
the projects or to make sure that the requirements laid out by the customer were being
met. The developers worked only on what was asked to be done.

The Journey

The team at Krizp System was introduced to the concepts behind the different Agile
frameworks. The XP method was employed over a span of one month and the results
were assessed.

The CEO of the company took on 2 roles: the customer representative and the tracker.
For his first role, he prioritized user stories, delegated them to the development team,
and had regular communication with the customer. As the tracker, he kept track of the
time to complete specific tasks. The CEO also initiated the planning game every week
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

(or at least once in four days), as the project was small and developers could complete
tasks in one user story faster. However, the customer was available for direct
communication only twice per month and the rest of the time he was in contact
through phone calls and e-mail.

The Paired Programming technique was adopted whereby both developers worked
together. After task completion, both of the developers reviewed the code with the
CEO.

Customer tests were introduced and the team worked on continuous design
improvements, which were about 12-15 per month.

Summary
The XP approach seemed to have a good impact on the software development cycle
for the company. Some of the positive changes included:

1. Better team collaboration, communication, and feedback

2. Better task and time management, and
3. Increased CEO involvement without technical contribution.

Extreme Programming Practices for IBM and Sabre

Airlines
The Problem

To assess the practical applications of Waterfall vs. Extreme Programming, a research

study was conducted through 2 case studies: one at IBM and the other at Sabre
Airlines. Each case study compared the waterfall approach to the XP approach.

The Journey

In the first case study, at IBM, the researchers wanted to study the impact of adopting
the XP approach on productivity, quality, and customer satisfaction. A year-long
study was conducted on a team of 7 – 11 members regarding the adoption of XP
practices. The team was responsible for developing Servlet/XML applications for a
toolkit utilized by other IBM teams to create products for external customers. The
case study analyzed 2 approaches on consecutive releases of the same product. The
first one was the traditional waterfall approach and the second was XP.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

In the second case study, at Sabre Airline Solutions, the same method was used i.e.
comparing 2 approaches through different releases of the same product. The team
worked on developing a scriptable GUI environment for external customers to
develop customized end-user and business applications. The team comprised 6-10
members. The old release was finished 3 years prior (spanning 18 months) using the
waterfall method whereas the new release was completed recently (spanning 3.5
months), using XP.

The first step was to establish an Extreme Programming Evaluation Framework (XP-
EF), which comprised three parts: XP Context Factors (XP-cf), XP Adherence
Metrics (XP-am), and XP Outcome Measures (XP-om):

• XP Context Factors (XP-cf): XP-cf was used to record important information

related to the project. These factors included team size, project size, criticality,
and staff experience.
• XP Adherence Metrics (XP-am): Through XP-am, the extent to which the
team uses the XP practices was expressed. The XP-am also helped in
investigating the interactions and dependencies amid the XP practices as well
as the degree to which the practices can be detached or removed.
• XP Outcome Measures (XP-om): XP-cm enabled assessment of business-
related results i.e. productivity, quality, etc.

In addition to the framework, interviews were conducted with team members and
customers to help understand the incorporation of XP by the team for the customer’s
satisfaction.

Summary
At IBM, the XP method seemed more productive compared to the waterfall method
by the following measures:

• Test Defects: for pre-release, the defects were 50% lesser and for post-release,
the defects were about 40% lesser in the release through the XP approach.
• Productivity: There was a significant increase in staff productivity using the
XP approach than in the waterfall method.
• Customer Satisfaction: Customer satisfaction was noted to be high in XP and
documented as N/A for the waterfall.
• Morale: The morale of the stakeholders was recorded as high in XP and
documented as N/A for the waterfall.

At Sabre Airlines, similar results were noticed:

 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

• Defect Collection Period: As the first release was created over 18 months, the
defect collection period was also longer in the waterfall-based approach. It was
significantly shorter in XP base release.
• Test Defects: for pre-release, the defects were 65% lesser and for post-release,
the defects were about 46% lesser in the release through the XP approach.
• Productivity: Staff productivity using the XP approach was about 46% higher
than in the waterfall method.
• Customer Satisfaction: Customer satisfaction was noted to be high in XP and
documented as N/A for the waterfall.
• Morale: The morale of the stakeholders was about 68% XP and documented as
N/A for the waterfall.

Use Cases and Application

Use Case 1: Web Development
Problem Statement: The company website needs to be redesigned.

Actors: Customer, Developers, Tracker

1. Regular Flow of Events:

2. The customer informs of initial requirements.
3. The development team starts programming.
4. The QA team tests for bugs and informs the programming team
5. The customer has more requirements
6. The cycle repeats.

Using XP:

1. Face-to-face meeting is called involving the customer and developers.

2. The customer defines requirements, the budget, and the timeline in the form of
a story.
3. The Project Manager becomes the Tracker and tracks the project’s progress.
4. The development team starts working in pairs. The code is written and
debugged at the same time.
5. Each week a meeting is held to discuss the progress. The customer can define
new requirements.
6. Every quarter a meeting is held to discuss the status of the stories.
7. After old stories are completed, a new set of stories are formed (requirements
for the next quarter)
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

Use Case 2: Game Development

Problem Statement: A client requires a game to be developed from scratch.

Actors: Customer, Developers, Tracker

Regular Flow of Events:

1. The customer gives requirements, time, and budget.

2. The developers start programming.
3. The QA team tests the game modules.
4. The customer has more requirements.
5. The cycle repeats.

Using XP:

1. Face-to-face meetings is called involving the customer and developers.

2. The customer defines requirements, the budget, and the timeline in the form of
a story (game modules).
3. The Project Manager becomes the Tracker and tracks the game development
progress.
4. The development team starts working in pairs. The code for different modules
is written and debugged at the same time.
5. Each week a meeting is held to discuss the progress. The customer can define
new requirements.
6. Every quarter a meeting is held to discuss the status of the stories.
7. After old stories are completed i.e. high priority modules are finished, a new set
of stories are formed (requirements for the next quarter)

nTask for Extreme Programming Practices (XP)

nTask is a Task Management System that supports the Agile method of Extreme
Programming framework. It is an online task management application designed
specifically for teamwork and project delivery. Regardless of the industry, nTask
facilitates the XP methodology and contributes to effective project planning and
process alignment.

The following are some of the ways nTask can help you plan and achieve your project
goals better, all within the XP framework.

1. Meeting Scheduling
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

You can schedule your sit-ins, weekly meeting as well as quarterly meetings
beforehand. The agenda and timings of the meetings can be specified. You may define
a fixed time for the meeting or send out a suggested time to the team, to be finalized
after team responds.

This application also allows you to note down all the important points discussed in a
meeting. The minutes can be then reviewed and published for the rest of the team.

2. Team Allocation
You may arrange your team and the roles they will undertake through the team
allocation section. You can easily define roles for the developers, the trackers, and the
customer.

3. Project Creation
The customer may create the project and specify the requirements. The customer can
also define the budget and timeline.

Task Creation and Assignment

The customer can create stories by creating tasks within the project. The tasks will
comprise a list of activities to complete under one story. These stories can then be
assigned to the programmers.

If the stories are completed before time by some of the team members, the customer
can assign them the “slack” tasks i.e. lower priority tasks within the remaining
timeline. This saves time working faster towards project completion.

1. Project Flow
The Project Manager or Tracker can help keep track of the project flow through the
Timesheet module. This module allows for effective monitoring and evaluation of
project progress. It helps individually assess the timeline for different tasks as well as
the milestones reached or pending.

2. Easy Collaboration
At times it is not possible to hold face-to-face meetings e.g. when a certain team is
working on another site. In such cases, automated updates on projects, tasks, and
meetings can ensure timely and effective team collaboration and discussion. This
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

avoids time being wasted in the manual arrangement of project and task follow-up,
communicating meeting of minutes, or project updates.

Real-Time Comments provide an easy way to communicate with the team. Whether it
is the exchange of information or new ideas, this makes it easy for the team to stay on
the same page.

The interdependent tasks are highlighted and each team member can check the
updates instantaneously as updated by the other team members. This keeps the team
updated on the changing situations and in planning the next task, accordingly.

Moreover, the customer can directly collaborate with the team and update any change
in requirements.

3. Transparency
nTask gives a transparent view of all the projects and corresponding tasks and sub-
tasks through its Taskboard. Any project created or modified is communicated to the
team, immediately. There is no need for rechecking progress updates, meeting
invitations, or project reports.

The tasks updated, modified, or deleted paves way for the entire team to be fully
aware and know exactly what is being accomplished and when.

With its Filter option, you can choose to see updates for selected projects based on
priority or the task at hand. With the Status option, the status of the selected task can
be seen as whether it has started or not, completed or in progress.

What is XP framework and extreme programming

methodology?
Extreme Programming (XP) is a software development process that was created to
address the challenges of developing complex software. It is an agile methodology
that focuses on collaboration, flexibility, and simplicity for both the developer and the
end user.

XP’s primary goal is to deliver working software in an iterative fashion through rapid,
continuous feedback from stakeholders.
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

XP Framework is a framework designed to support Extreme Programming (XP)

methodologies by providing developers with specific tools, structures, and
conventions that are tailored toward extreme programming.

It provides structures such as test-driven development (TDD), refactoring, continuous

integration, and delivery, among many others. Using these structures helps developers
produce better-quality code faster while helping them remain organized throughout
the software development process.

The XP methodology can be seen as four interlocking parts: Communication,

Simplicity, Feedback, and Courage. Communication emphasizes open communication
between all team members; Simplicity encourages keeping coding solutions simple;
Feedback looks at providing users feedback early and often during the project; finally,
Courage allows developers to make decisions based on their own best judgment
without fear of repercussions from higher authority figures or management teams.

What are the phases of XP in project management?

XP, or extreme programming, is a specific type of project management methodology.
It focuses on creating high-quality software in a rapid and cost-effective manner. XP
has five core phases that help guide the development process: planning, analysis,
design, coding, and testing. Each of these steps can be broken down further into
smaller tasks.

1. Planning
During this phase of XP project management, the team identifies the overall goal of
the project and any constraints that will affect its success (such as budget or timeline).
Once a clear vision is set for the end product, then it’s time to break down tasks into
manageable pieces to move forward with development.

2. Analysis
In this stage of XP project management, developers investigate existing systems (if
applicable) to better understand user needs and identify potential areas that need
improvement or optimization within existing processes. This step also helps inform
more optimal solutions during later design stages in order to create superior products.

3. Design
 INTRODUCTION TO EXTREME PROGRAMMING (XP) Unit-V

At this point in the process, all user requirements have already been identified from
previous analysis steps so it’s time to start developing a plan for how they will be met
through code development techniques such as object-oriented programming or
structured query language (SQL). The goal here is not just creating effective code but
also designing it in an efficient way so resources are used optimally.

4. Coding
After finishing up designs from earlier steps then it’s time for developers to actually
write their code! This usually involves multiple short cycles where the first code gets
built out quickly with simple features followed by additional rounds where needed
features are added on top until desired functionality has been reached.

5. Testing
Last but not least comes testing! All written code gets verified through different types
of tests including unit testing plans which verify individual pieces work correctly;
integration tests which ensure different functionalities work together properly; system
tests which confirm larger components function like expected.