What is Extreme Programming (XP)

Developed by Kent Beck when working for Chrysler in

1996.
Software development-centric Agile method.
It places a strong emphasis on technical practices in
addition to the more common teamwork and structural
practices.
The tight feedback loop also allows XP teams to refine
their plans quickly.
XP is a discipline of business software development
that focuses the whole team on common, reachable
goals, using values and principles and practices of XP.
Teams apply appropriate practices in their own
context.

Plan

Analysis
Design
Code
Test
Deploy

$
$
$
$
$
$
$
$

Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration
Iteration

$
$
$
$

Iteration

Iteration

Iteration

Iteration

Iteration

XP Lifecycle

$ = Potential
Release

XP Values
1

Communication

Simplicity

Feedback

Courage

Respect

XP Values
Communication:

Communication is
important for creating a sense of team and effective
cooperation. The value focuses on making sure all
the team members know what is expected from
them and what other team members are working on.
The daily stand-up meeting is a key communication
component.

Simplicity:

Keep it simple. This value focuses

on reducing complexity, extra features, and waste
Feedback: To learn the appropriate lessons at every
possible opportunity.

XP Values
Feedback:

To learn the appropriate lessons at every

possible opportunity.

Courage:

To make the right decisions, even when

theyre difficult, and to tell stakeholders the truth when
they need to hear it.

Respect:

If members of the team don't care about

each other and what they are doing, XP won't work. If
members of the team don't care about the project,
nothing can save it. Every person whose life is touched
by software development has equal value as a human
being. No one is intrinsically worth more than anyone
else. For software development to simultaneously

XP Practices

(Source: http://www.xprogramming.com/xpmag/whatisxp.htm)

XP Primary Practices
Test First Programming
Programming

Incremental Design
Pair Programming

Integration

Ten Minute Build

Continuous Integration
Sit Together

Primary
Practices

Information Workspace
Energized Work/ Whole
Team
Stories
Planning

Weekly/Quarterly Cycle
Slack

XP Practices: Whole Team

All contributors to an XP project are one
team
Must include a business representative-the Customer
Provides requirements
Sets priorities
Steers project

Team members are programmers, testers,

analysts, coach, manager
Best XP teams have no specialists

XP Practices: Planning Game

Two key questions in software
development:
Predict what will be accomplished by the due
date
Determine what to do next

Need is to steer the project

Exact prediction (which is difficult) is not
necessary

XP Practices: Planning Game

XP Release Planning
Customer presents required features
Programmers estimate difficulty
Imprecise but revised regularly

XP Iteration Planning

Two week iterations

Customer presents features required
Programmers break features down into tasks
Team members sign up for tasks
Running software at end of each iteration

XP Practices: Customer Tests

The Customer defines one or more
automated acceptance tests for a feature
Team builds these tests to verify that a
feature is implemented correctly
Once the test runs, the team ensures that
it keeps running correctly thereafter
System always improves, never backslides

XP Practices: Small Releases

Team releases running, tested software
every iteration
Releases are small and functional
The Customer can evaluate or in turn,
release to end users, and provide
feedback
Important thing is that the software is
visible and given to the Customer at the
end of every iteration

XP Practices: Simple Design

Build software to a simple design
Through programmer testing and design
improvement, keep the software simple
and the design suited to current
functionality
Not a one-time thing nor an up-front thing
Design steps in release planning and
iteration planning
Teams design and revise design through
refactoring, through the course of the
project

XP Practices: Pair Programming

Pair Programmin
g

XP Practices: Pair Programming

All production software is built by two
programmers, sitting side by side, at the
same machine
All production code is therefore reviewed
by at least one other programmer
Research into pair programming shows
that pairing produces better code in the
same time as programmers working singly
Pairing also communicates knowledge
throughout the team

XP Practices: Test-Driven Development

Test-Driven Developmen
t

XP Practices: Test-Driven Development

Teams practice TDD by working in short
cycles of adding a test, and then making it
work
Easy to produce code with 100 percent
test coverage
These programmer tests or unit tests are
all collected together
Each time a pair releases code to the
repository, every test must run correctly

XP Practices: Design Improvement

Continuous design improvement process
called refactoring:
Removal of duplication
Increase cohesion
Reduce coupling

Refactoring is supported by
comprehensive testing--customer tests
and programmer tests

XP Practices: Continuous Integration

Teams keep the system fully
integrated at all times
Daily, or multiple times a day builds
Avoid integration hell
Avoid code freezes

XP Practices: Collective Code Ownership

Any pair of programmers can improve any
code at any time
No secure workspaces
All code gets the benefit of many peoples
attention
Avoid duplication
Programmer tests catch mistakes
Pair with expert when working on
unfamiliar code

XP Practices: Coding Standard

Use common coding standard
All code in the system must look as
though written by an individual
Code must look familiar, to support
collective code ownership

XP Practices: Metaphor
XP Teams develop a common vision of the
system
With or without imagery, define common
system of names
Ensure everyone understands how the
system works, where to look for
functionality, or where to add functionality

XP Practices: Sustainable Pace

Team will produce high quality
product when not overly exerted
Avoid overtime, maintain 40 hour
weeks
Death march projects are
unproductive and do not produce
quality software
Work at a pace that can be sustained
indefinitely

XP Principles

Humanity
Economics
Mutual benefits
Self similarity
Improvement
Diversity
Reflection

Flow
Opportunity
Redundancy
Failure
Quality
Baby steps
Accepted responsibility

XP Roles
Product Owner/ On-Site
Customers

Domain Experts/SMEs
Interaction Designers

Business Analysts
Programmers
Designers and Architects
Technical Specialists
Testers
Coaches
Programmer Coaches
Project Manager/Product

Fractional assignment
is counterproductive
XP team should include
exactly the expertise
necessary to complete
the project successfully
and cost effective.
Roles on a mature XP
team aren't fixed and
rigid

XP Key Concepts

Refactoring
Technical Debt
Time-boxing
Last Responsible Moment
Stories
Iteration
Velocity
Theory of constraints (TOC)
Mindfulness

Refactoring

There are multiple ways of expressing

the same concept in source code. Some
are better than others.
Refactoring is the process of changing
the structure of the code - rephrasing it without changing its meaning or
behavior.
Its used to improve code quality, to
fight off softwares unavoidable entropy,
and to ease adding new features.

Technical Debt
Technical debt is the total amount of less-than-perfect design
and implementation decisions in your project.
When a team produces software without using good practices such
as TDD, continuous integration, and refactoring, it may incur
technical debt.
Like financial debt, technical debt accrues interest that will cost the
team more at a later date.
Sometimes this debt may be worthwhile, such as to take advantage
of a sudden business opportunity.
Usually, though, technical debt compounds and slows the team's
velocity. Less and less business value can be produced in each
iteration because the code lacks a safety net of automated
regression tests or has become difficult to understand and maintain.
The key to managing it is to be constantly vigilant. Avoid shortcuts,
use simple design, and refactor relentlessly.

Time-Boxing
Recognizing the point at which you have enough
information is not easy. If you use time-boxing,
you set aside a specific block of time for your
research or discussion and stop when your time
is up, regardless of your progress.
This is both difficult and valuable. Its difficult
to stop working on a problem when the
solution may be seconds away. However,
recognizing when youve made as much
progress as possible is an important timemanagement skill. Time-boxing meetings, for
example, can reduce wasted discussion.

Last Responsible Moment

XP views a potential change as an opportunity to
exploit; its a chance to learn something
significant. This is why XP teams delay
commitment until the last responsible
moment.
That, in turn, decreases your workload by
reducing the amount of rework that results
from incorrect decisions. Changes are easier
because they are less likely to invalidate
decisions or incur additional rework.

Stories

Stories represent self-contained,

individual elements of the project.
They tend to correspond to individual
features and typically represent one or
two days of work.
Stories are customer-centric, describing
the results in terms of business
results. Theyre not implementation
details, nor are they full requirements
specifications. They are traditionally just
an index cards worth of information used
for scheduling purposes.

Iteration
Iteration is the full cycle of design-code-verify-release
practiced by XP teams.
Its a time-box that is usually one to three weeks long.
Each iteration begins with the customer selecting which
stories the team will implement during the iteration, and
it ends with the team producing software that the
customer can install and use.
The beginning of iteration represents a point at which
the customer can change the direction of the
project.
Smaller iterations allow more frequent adjustment.
Fixed-size iterations provide a well-timed rhythm of
development.

Velocity
In well-designed systems, programmer estimates of effort tend
to be consistent but not accurate.
Programmers also experience interruptions that prevent effort
estimates from corresponding to calendar time.
Velocity is a simple way of mapping estimates to the
calendar.
Its the total of the estimates for the stories finished in iteration.
In general, the team should be able to achieve the same
velocity in every iteration.
This allows the team to make iteration commitments and
predict release dates.
The units measured are deliberately vague; velocity is a
technique for converting effort estimates to calendar time and
has no relation to productivity.

Theory of Constraints (TOC)

Theory of Constraint says, in part, that every system has
a single constraint that determines the overall
throughput of the system.
Draw your current process as series of linked activities
and look for where work piles up.
TOC can help find bottleneck, but what if bottleneck has
nothing to do with software?
TOCs weakness is its a model, a map. People develop
software which are not boxes in a model: however TOC is
good way to become aware of your process

Mindfulness
To respond effectively to change - requires that everyone
pay attention to the process and practices of development.
This is mindfulness.
Sometimes pending changes can be subtle. You may realize
your technical debt is starting to grow when adding a new
feature becomes more difficult this week than last week.
You may notice the amount and tone of feedback you
receive from your customer's change.
XP offers plenty of opportunities to collect feedback from
the code, from your coworkers, and from every activity you
perform. Take advantage of these.
Pay attention. See what changes and what doesnt, and
discuss the results frequently.

Discussion: Technical Debt

Technical Debt

15
Minutes

Do you consider defects/bugs part of

technical debt?
Do you consider product improvements
part of technical debt?
How do you measure technical debt for
your team?

Discussion: time-boxing

Time-box technique

10
Minutes

Is it a must to have time-boxing practice

in Agile?
Discuss the benefits of time-boxing
Under what circumstances time-boxing is
not beneficial