XP Programming

A Brief History of Extreme Programming

XP’s origin dates back to the 90s when Kent Beck – who would later become one of the
authors of the Agile Manifesto – created it when hired to lead Chrysler’s
Comprehensive Compensation System team.

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

develop a software.
How Does Extreme Programming (XP) Work?

XP is built upon values, principles, and practices, and its goal is to allow small
to mid-sized teams to produce high-quality software and adapt to evolving and
changing requirements.
Test-First Programming
Write failing automated test -> Run failing test -> develop code to make
test pass -> run test -> repeat
 XP Values
Values offer teams purpose, guiding them in making high-level decisions. However,
values are abstract and difficult to apply in concrete terms in the real world. The five
values are:
Communication: You can’t work together effectively without sharing knowledge, and
you can’t share knowledge without communication.
Simplicity: Developers can save time and effort by writing simple, effective code that
works properly. Ultimately, the less complex code enhances product value.
Feedback: Early, constant feedback is ideal for team members who release frequent
software deliveries, helping them to adjust as the project evolves and changes. The
sooner programmers know that the product requires changes, the easier it is to create
those changes (and less painful).
Respect: Every team member cares about their work, and everyone contributes.
Courage: It takes guts to admit you're mistaken and that your idea didn't work and must
be changed. Being honest takes courage, and you need honesty in providing realistic
estimates, even if stakeholders don't like the truth. for instance, honest estimates.
Giving and receiving feedback also takes courage
 XP Principles

Fast feedback: This principle means getting feedback quickly and responding to
it fast, and not putting it off.

Assumed simplicity: Team members must direct their energy on whatever task
has the highest priority and avoid unnecessary or redundant jobs. Keep it
simple.

Incremental changes: It's better to make small changes step-by-step than to let
them accumulate and handle them all simultaneously.

Embrace change: Speaking of changes, if the client wants to modify the product,
programmers should support the idea and map out how they will incorporate
the new changes.

Produce quality work: A team that works well together will inevitably create a
superior product and take pride in the result.
Key Roles and Responsibilities
According to Kent Beck, a mature XP team shouldn’t rely on rigid roles, but
recognize that roles can be useful for beginner teams, until they start to get in
the way of collaboration. That said, there are some common roles that people
associate with XP:
Customer: ideally, there should be a real customer on-site to answer questions,
prioritize user stories or collaborate with acceptance testing. When this isn’t
possible, this role could be fulfilled by a customer representative.
Programmers: in an XP team, programmers estimate the effort needed to
complete tasks and stories, write automated tests, and implement the stories.
Coach: Having a coach isn’t required, and many teams have achieved success
without one. However, having someone experienced in XP to coach a team can
ensure the team members follow the practices, turn them into habits and don’t
revert to the old ways.
Tracker: A tracker tracks the team’s progress metrics and talks with every team
member to identify roadblocks and figure out solutions. The tracker calculates
the metrics that indicate how well the team is doing, such as velocity and
burndown charts, or the team uses a digital scrum or kanban board that
calculates them automatically.
XP Practices
The interconnected set of practices listed below are the heart and soul of
extreme programming. There were originally a dozen practices, but over time
they have been refined and whittled down. This list of practices is the most
current.
Sit together: This principle harkens back to the value of communication. A face-
to-face conversation is typically the best means of communication, so the team
should sit together in the same area without walls or dividers.
Whole team: The whole team comprises a cross-functional group of people,
each having a needed role in contributing to product development. Everyone
plays their part and works together daily.
Informative workspace: Since the team should sit together, the workspace
should be conducive to this. However, there need to be some privacy
provisions.
Energized work: Team members should take whatever steps are needed to be
physically and mentally focused. These steps include being free from
distractions, not overworking, staying healthy, and respecting your teammates.
Pair programming: All production software is created by a pair of people sitting
at the same machine, a riff on the idea of needing two sets of eyes to spot
mistakes.
Stories: Stories describe the product’s uses in terms that the
customers and users can relate to. In addition, these stories help
developers and programmers plan their work.

Weekly cycle: Weekly cycles are analogous to iterations. The

team meets at the start of the week to discuss the progress to
date. The customer chooses the stories to be worked on that
week. The team decides how to tackle them.

Quarterly cycle: Quarterly cycles are comparable to releases and

keep each weekly cycle’s detailed work in line with the overall
project. The customer shares the overall plan for the team in
context with the features to be done within a quarter.

Slack: Throw in some low priority assignments or stories into the

weekly and quarterly cycles that can be dropped if the team falls
behind on the higher priority stories or tasks.
Ten-minute build: The ten-minute build’s ultimate goal is to automatically build
the entire system and run every test within ten minutes. This practice motivates
the team to increase their reliance on build process automation.

Continuous integration: Immediately test code changes when they are added
into the larger codebase, helping team members spot errors and integration
issues as they happen.
Incremental design: This practice recommends that programmers do a small bit
of work up-front to grasp the correct perspective of the system design, then go
deep into the details of a given aspect of the design when delivering specific
features. This method is a cost-effective way of making changes and gives
programmers the most up-to-date information they require to make design
decisions.

Test-first programming: Instead of developing code, writing tests, then running

tests, this practice has programmers following this sequence:
•Write a failing automated test
•Run a failing automated test
•Develop code to make the test pass
•Run test
•Repeat
 start off by describing the desired results of the project by having customers
define a set of stories. As these stories are being created, the team estimates the
size of each story.

This size estimate, along with relative benefit as estimated by the customer can
provide an indication of relative value which the customer can use to
determine the priority of the stories.

If the team identifies some stories that they are unable to estimate because they
don’t understand all of the technical considerations involved, they can
introduce a spike to do some focused research on that particular story or a
common aspect of multiple stories.

Spikes are short, time-boxed time frames set aside for the purposes of doing
research on a particular aspect of the project. Spikes can occur before regular
iterations start or alongside ongoing iterations.
Next, the entire team gets together to create a release plan
that everyone feels is reasonable. This release plan is a first
pass at what stories will be delivered in a particular quarter or
release. The stories delivered should be based on what value
they provide and considerations about how various stories
support each other.

Then the team launches into a series of weekly cycles. At the

beginning of each weekly cycle, the team (including the
customer) gets together to decide which stories will be
realized during that week. The team then breaks those stories
into tasks to be completed within that week.
At the end of the week, the team and customer review
progress to date, and the customer can decide whether the
project should continue, or if a sufficient value has been
delivered.
 What is Scrum?

Scrum is a framework for developing and sustaining complex

products.

Sutherland and Schwaber defined Scrum as the framework to

achieve mentioned action and developed numerous rules,
events, and artifacts.

Scrum is based on three main components: roles,

ceremonies, and artifacts.
Scrum values for project teams
Scrum Teams follow five core values.
Commitment
Scrum Team members are committed to time-based tasks and goals and are dedicated to
continuous improvement to find the best solution.

Courage
Scrum Teams show courage by asking open, challenging questions. They have honest and
transparent discussions to arrive at the best solution.

Focus
During any given period, team members will work from a Product Backlog of tasks. They
will focus on the selected tasks to provide deliverables within a limited time frame.

Openness
Scrum Team members are open to new ideas and opportunities that support individual
learning and overall project quality.

Respect
Team members respect the project managers, each other, and the Scrum process. This
culture of respect creates a spirit of mutual collaboration and cooperation within the team.
Scrum is based on three main components: roles, ceremonies, and
artifacts.
1. Roles: In Scrum, there are three main roles: Product Owner, Scrum Master,
and Development Team.
Product owner (PO)
Is the representative of the stakeholders and customers who use the software.
They focus on the business part and is responsible for the ROI of the project.
They Translate the vision of the project to the team, validate the benefits in
stories to be incorporated into the Product Backlog and prioritize them on a
regular basis.
Scrum master
The person who leads the team guiding them to comply with the rules and
processes of the methodology. Scrum master manages the reduction of
impediments of the project and works with the Product Owner to maximize the
ROI.

Scrum Team
A group of professionals with the necessary technical knowledge who develop the project
jointly carrying out the stories they commit to at the start of each sprint.
 2. Ceremonies
In Scrum, there are four main ceremonies: Sprint Planning, Daily Scrum,
Sprint Review, and Sprint Retrospective.

Sprint Planning: At the beginning of each Sprint, the Scrum Team conducts a
Sprint Planning meeting. This event focuses on setting the Sprint Goal and
selecting items from the Product Backlog to work on during the Sprint.

Daily Scrum: The Daily Scrum, or Daily Standup, is a brief, daily event where the
Development Team synchronizes its activities. Each member shares what they’ve
worked on, what they plan to do, and any impediments they’re facing.

Sprint Review: After the Sprint, the Scrum Team holds a Sprint Review to
showcase the work completed during the Sprint. Stakeholders provide feedback,
and the Product Backlog is adjusted as needed.
Sprint Retrospective: The Sprint Retrospective takes place
after the Sprint Review and is a reflective event. The Scrum
Team inspects its processes and identifies improvements for
the next Sprint.

Backlog Refinement: While not an official ceremony, Backlog

Refinement involves regularly refining and clarifying the
Product Backlog to prepare items for future Sprints.
3. Artifacts

There are three main artifacts in Scrum: Product Backlog, Sprint Backlog, and
Product Increment.

Scrum Artifacts are designed to guarantee the transparency of key

information in decision making.
Product Backlog (PB): The product backlog is a list that collects everything
the product needs to satisfy the potential customers. It is prepared by the
product owner and the functions are prioritized according to what is more
and less important for the business. The goal is for the product owner to
answer the question “What should be done”.

Sprint Backlog (SB): It is a subset of items of the product backlog, which are
selected by the team to perform during the sprint on which they are going to
work. The team establishes the duration of each Sprint. Usually the sprint
backlog, is displayed on physical boards called as Scrum board – that makes
the development process visible to everyone who enters the development
area.
Increment: The Increment is the sum of all the tasks, use cases, user stories,
product backlogs and any element that was developed during the sprint and
that will be made available to the end user in the form of Software.