Introduction to XP

This is an introduction to the XP (Extreme Programming)
method of developing software. It is based loosely on Kent Beck’s book
“Extreme Programming Explained” and mainly on my own experiences in using
XP. This introduction shortly explains the basics behind XP, how each XP
practice relies on other practices, with heavy testing being the founding
base, and how the XP process works. This intro does not cover the motivation
– why XP is useful. I assume that since you’re already here, you’ve found
out that traditional processes have their problems.

Behind the scenes

Values

XP is founded on 4 values, which are:

Communication

All interested parties must understand each other and communicate regularly.

Simplicity

A simple design cannot contain as many bugs as a complex one, so the system needs to be kept as simple as possible. A complex system is less easy to understand, which also adds problems.

Feedback

The domain experts must be able to continually steer the development in the right direction, while the technical staff provides them with the information on technical restrictions and possibilities.

Courage

Make bold decisions – make simple designs (they will work), code fast (rely on the automatic tests), make changes (refactor as needed, throw away dysfunctional code).

Principles

XP has 5 basic principles, which are:

Rapid feedback

The process needs to be self-steering, so feedback from all parties to others must be given quickly, and reacted to quickly.

Assume simplicity

Every problem should be solved as simply as possible, bordering on ridiculous. Most of the time simple solutions will work, and the few truly complex issues can be tackled when the simple solution doesn’t work. Time will be saved.

Incremental change

Make small incremental changes, not huge additions that will cause integration problems and slow down the feedback cycle.

Embracing change

Keep your options open and be ready to change the strategy at any time.

Quality work

While working fast, produce high quality results. Quality can only be “excellent”, no lower.

Practices

XP consists of 12 practices, which are shortly summarized here. Each practice supports others, making up a working system. Some practices may be left out without the system breaking up while others are mandatory.

The Planning Game

Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.

Small Releases

Put a simple system into production quickly, then release new versions on a very short cycle.

Metaphor

Guide all development with a simple shared story of how the whole system works.

Simple design

The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.

Testing

Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.

Refactoring

Programmers restructure the system without changing its behaviour to remove duplication, improve communication, simplify, or add flexibility.

Pair programming

All production code is written with two programmers at one machine.

Collective ownership

Anyone can change any code written anywhere in the system at any time.

Continuous integration

Integrate and build the system many times a day, every time a task is completed.

40-hour week

Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.

On-site customer

Include a real, live user on the team, available full-time to answer questions.

Coding standards

Programmers write all code in accordance with rules emphasizing communication through the code.

Synergy of the XP practices

The most critical part of XP is the testing – every feature and non-trivial function of the software must be covered by automated unit tests.

Comprehensive tests allow us to do major refactoring as needed. Whenever a feature needs more or different functionality, we can recode it the way it’s needed. The automated unit tests will report if the refactoring breaks anything else in the system. We can thus expand and evolve the system and its design incrementally.

Our ability to refactor at need removes the need for detailed system design
beforehand. By using a simple design, changing the design
is easier than when heavy design work has already been invested in. When implementation starts, you always have a high level design, which is followed, but details are kept as simple as possible. As the system evolves, the low level design will mature on its own along with the actual code. When implementing a new feature, one shouldn’t try to build it perfect and complete right away, but rather do a crude first version that does what is needed, and no more. Keeping the grand design in mind, though, will steer the solutions in the correct direction, making further changed less severe.

To make the actual coding process as flexible as possible, everyone should be able to change everything. Collective ownership means that no-one owns any piece of code, but rather that everyone can change any part of the system. This also requires that coding standards are in place so everyone writes code the same way. We also need a code repository that is accessible to everyone and everyone can make commits to that repository.

The product in the repository must be functional at all times if different developers are to work on it simultaneously. This means that no erroneous code can be committed. All unit tests must run 100%, before new changes can be committed to the repository. Each change to the system (task) should be doable in less than one day. Continuous integration means that programmers make small incremental changes, run the automated tests and make a commit when the tests run flawlessly. As a result, the product in the repository changes several times a day, but is always in working condition.

Pair programming is an excellent method to improve code quality. One programmers types the code and concentrates on the details, while the other monitors, makes sure that unit tests are written, spots errors and concentrates on the larger design. Several studies have shown that two programmers working as a pair are more productive than two separate programmers. As part of code quality, no overtime should be used – a tired programmer isn’t creative, and it often requires creativity to find the most elegant, simple solution to a given problem. Tired programmers make easy but bad solutions.

Keeping the product always functional allows us to keep make small releases in a quick cycle – a new version can be released virtually daily, if needed.

The production team needs to have domain experts (customers) in it. The customer knows how the system is going to be used and can steer the development in the right direction. He can also spot mistakes and bad design quickly (since we have a short release cycle and the product is always functional). To make sure that the programmers and the customer understand each other, the system has to be described using a simple metaphor that everyone understands.

The planning game is the meeting where the customer and the programmers meet and plan the next cycle. The metaphor is used to make sure everyone understands the concepts and can communicate.

High level planning in XP

The milestones in the XP process are the Planning Game meetings, where Development and Business meet. Development is represented by the programmers and designers, while Business is represented by management, domain experts (customers) and marketing.

The Planning Game cycle can vary from a few weeks to several months. At each meeting the project plan is extended to cover the time until the next meeting. After each cycle, a new release is made.

An release cycle is divided into three phases that follow each other.

Exploration phase

Business writes story cards that clearly tell what features are needed in the system. Story cards can describe new features or changes to existing ones.

Development estimates how long each story will take to implement. This estimate is in IED (Ideal Engineering Time), meaning coding with nothing else to do and no interruptions or problems.

If a story can’t be estimated, it is split into smaller stories. Also if one part of a story is more important than others, the story can be split.

Commitment phase

Business sorts the stories into those that are vital, those that are significant and those that would be nice to have.

Development sorts the stories into those that can be esimated precisely, reasonably well or not at all.

Development tell Business the velocity, or, how much IET the team can complete per calendar month.

Business selects the cards that are to be included in the next release, either by first choosing the date and selecting appropriate cards, or first choosing the cards and calculating the release date from their estimates.

Steering phase

Steering is divided into iterations of 1-3 weeks in length. At the beginning of each iteration, Business selects one iteration’s worth of the most valuable stories that should be implemented. The very first iteration should include the stories that make up a working system.

If Development has overestimated its velocity, it can recover by asking the Business to leave out the least valuable stories from the release.

If Business needs a new story in the middle of development, it can write the new story, have Development estimate it and remove other stories to make room for it.

If Development feels that the plan is no longer accurate, it can reestimate all remaining stories and recalculate its velocity.

Low level planning in XP

Iteration planning is done within one iteration and only involves Development. It also contains three phases.

Exploration phase

Turn the stories of the iteration into tasks. Normally a story produces several tasks and sometimes one task can support several stories.

If a task takes longer than a few days, it needs to be split into smaller tasks. Also several one hour tasks should be combined into larger tasks.

Commitment phase

Each programmer accepts responsibility for a task.

The responsible programmer estimates the task in IET days.

Each programmer select his load factor – how many IET days he can complete in an iteration. This data comes from previous iterations. The load factor can range from 2 to 8 days in a three week iteration when half the time of each programmer is used in pair programming.

Each programmer adds up the task estimates he’s committed to and multiply by their load factor. Overcommitted programmers must give up tasks. If the entire team is overcommitted, they must recover in the Planning Game Steering phase.

Steering phase

Each programmer takes a task, finds a partner, writes the test cases, codes until they all work, integrates until all tests run and then commits.

One team member should collect information on progress – how much time each programmer has spent on each task and how much time is left.

If a programmer is overcommitted, he can reduce the scope of some tasks, ask the customer to reduce the scope of some stories, leave out nonessential tasks, getting more help, or asking the customer to leave some stories to a later iteration.

More information

www.extremeprogramming.org
contains good reference information on the practices of XP and helpful
diagrams of the process.