Agile Management Series 2: Agile and Extreme Programming – Part 1

By Arul Muthupandian B.Sc, PG Diploma in IT Management (UK), PMP, PMI-ACP, ITIL

Group Manager, PMI-ACP Credentialed Group

Group Leader, Star PMO

Trainer and blogger, Simplilearn

Introduction to Extreme Programming (XP):

Extreme programming (XP) was developed by Kent Beck during his work on the Chrysler
Comprehensive Compensation System (C3) payroll project. Although extreme programming
itself is relatively new, many of its practices are around for some time as it just takes "best
practices" to extreme levels.

XP is an agile methodology which is predominantly intended to improve product quality and

responsiveness to changing customer requirements. It advocates frequent "releases" in short
development cycles called “timeboxing”.

Extreme programming includes paired programming or doing extensive code review, Test
Driven development (TDD), last responsive moment, a flat management structure, simplicity and
clarity (in code), waiting till the problem is clear, frequent communication with the customer and
programmers. This methodology offers benefits that are taken "extreme" levels, on the theory
that if a little is good, more is better. XP is still evolving, assimilating more lessons from
experiences in the field, to use other practices and has added more values and practices.

XP reduces the cost of changes in requirements by executing multiple-incremental short

development cycles, rather than a long one. XP looks at changes as natural, inescapable and
desirable, and must be planned for instead of defining a stable set of requirements. XP uses a
number of basic values, principles and practices on top of the agile framework.

Activities

XP has four basic activities within the development process e.g., like coding, testing, listening,
and designing in software development process. Each of those activities is described below:

1. Coding (Development)

XP states that the only truly important outcome is the resulting product (service or software
code) without the product (or code), there is no outcome of the development process.

Product (or code) can also be used to figure out the most suitable solution or to communicate
problems. A complex development problem can be explained by using the product to
demonstrate what he or she means, as it is always clear and concise. It cannot be interpreted in
more than one way. Developers can also give feedback on the product by modifying the product
or code.

2. Testing

XP believes that if a little testing can eliminate a few flaws, a lot of testing can eliminate many
more flaws. Unit testing determines whether a given feature works as intended. A developer runs
many automated tests and if all tests run successfully, then the product is complete. Acceptance
tests verify that the requirements are met as per customer's satisfaction. These tests occur in the
exploration phase of release planning.
3. Listening (Feedback)

Developer must listen to customer’s business logic and their requirements. They must explain the
technological difficulties or abilities to the understanding of the customers.

4. Designing

Complexities and dependence of the system must be avoided. A good as well as a working
design that eliminates dependencies and the complexities, of changes to product from time to
time is important. This means that changing one part of the product will not affect other parts of
the product.

Values of XP

Extreme Programming believes in its five core values as given below:

1. Communication

Product development requires a good deal of communication to understand the customer’s

requirements. As the life cycle is short XP requires that product is built rapidly and knowledge is
disseminated to all the development team rapidly as well. This gives them a shared view of the
product as it is with the customers. Further, extreme programming favors simple designs,
common metaphors, collaboration of users and programmers, frequent verbal communication,
and feedback.

2. Simplicity

Extreme programming believes in starting with the simplest solution first and other
functionalities can be added later. It focuses on designing and coding for the needs of today
instead of those of tomorrow, next week, or next month with the help of good and efficient
design.

3. Feedback

In XP feedback is required from three dimensions of product development:

1. Product Feedback: by writing unit test , or running periodic integration tests, the developers get
direct feedback from the state of the product after every change.

2. Customer Feedback: The acceptance test written by the customer and the testers gives a
considerable feedback on the current state of the product. This feedback is done every two or
three weeks to let the customer easily steer the development.

3. Team Feedback: As the customers are involved in every aspect of the product development,
when customers come up with new requirements in the planning game, the team directly gives an
estimation of the time required to implement.
Any feedback is closely related to communication and simplicity. As Kent Beck says "Optimism
is an occupational hazard of programming. Feedback is the treatment."

4. Courage

The XP practices advocates courage like doing design and code for today. This practice helps in
avoiding getting bogged down in design and the effort that is being put in. Further courage is
required for the team to refractor the code or to throw away code that doesn’t satisfy the
requirements or to persistently working towards goal.

5. Respect

XP also believes respect for self and others. Developers should avoid anything that delays or
hinders the work of others.

Adopting these values requires a high level of motivation and loyalty towards the team, and
towards the goal of the project.

The rest in next article…