Extreme programming (XP) practices

// the article is part of my XP presentation/coaching session

What is XP?

Extreme Programming is an agile software development methodology based on values of simplicity, communication, feedback, courage, and respect. XP works by bringing the whole team together (+ the business person) in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation

History

XP was first introduced for a project called Chrysler Comprehensive Compensation System (C3 project) during 1996 – 1999. The project goal was: development of Payroll processing software for 87,000 employees. The dev team consisted of only 8 developers and for the first time a permanent business member was introduced in the team. In 1997 the new C3 system managed to pay 10,000 people. In 2000 DaimlerChrysler shut down the project and de facto banned XP, only to restore it a couple of years later. This is how XP practices were created (by developers for developers).

Pair programming

• One programmer has control over the workstation and is thinking mostly about the coding in detail. The other developer is focused mainly on the big picture. After a while both devs change places
• The huge advantage is that all production code is reviewed by at least one other programmer
• It leads to: better design, better testing, better code – overall much higher quality

Planning game

There are two parts of the “planning game”. The first one is called “release planning” and is a long-term planning

• The client/user presents the desired features to the programmers (high level)
• The programmers roughly estimate their difficulty
• The client/user elaborates a plan for the project / Initial release plans are imprecise: neither the priorities nor the estimates are truly solid – the goal is to have a rough vision / roadmap
• However, even the first release plan is accurate enough for decision making, and XP teams revise the release plan regularly

The second part of the “planning game” is the “iteration planning” itself

• The team is given direction each week/two weeks, delivering running useful software at the end of each iteration
• During iteration planning, the client might change priorities / break-down stories
• The programmers break stories into tasks, and estimate their cost (at a sufficient level of detail)
• The team commits for what will be undertaken in the current iteration – using the velocity from previous one

Test driven development

• Unit tests are written before the eventual code is coded (best practice)
• Therefore, the programmer is stimulated to think about conditions in which the code could fail
• The cycles of adding a test are very short, then checking if it works
• The “unit tests” are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the tests must run correctly. 100% all the time
• The programmers get immediate feedback on how they’re doing

Continuous integration

• The development team should always be working on the latest version of the software
• The teams keep the system fully integrated at all times
• Daily builds are for wimps: XP teams build multiple times per day
• The overall goal is to avoid the “integration hell” in the end

Refactoring

• Code, and other work artifacts, are continuously reviewed and kept as clean as possible
• It is not just sufficient that code works, it must also be clean and optimal
• The focus is on removal of duplication (a sure sign of poor design), and on increasing the “cohesion” of the code, while lowering the “coupling”
• XP teams start with a good, simple design, and always have a good, simple design for the software even a couple of months/years into development
• The benefit is sustainable development speed, and general increase of the speed as the project goes forward

Whole team

• All the contributors to an XP project sit together, members of one team
• The team must include a business representative — the “client/user” — who provides the requirements, sets the priorities, and steers/leads the project

Collective code ownership

• On an Extreme Programming project, any pair of programmers can improve any code at any time
• All code gets the benefit of many people’s attention, which increases code quality and reduces defects

Major principals

• One / two week iterations
• Program only what is needed today
• Use simple user stories and tasks - no story / task bigger than 1-2 days of development
• Collocated environment - face to face conversation all the time
• Daily feedback – XP teams want to fail quickly and keep on the right track
• Use spike solutions – to reduce the level of unknown in each future story
• Strictly ‘no overtime policy’ – well rested developers are productive developers

Resources used
www.extremeprogramming.org
www.xprogramming.com