Extreme Programming Practices

Building on the values of simplicity, communication, feedback, and courage, Extreme Programming is characterized by about a dozen key practices, 13 in the form I use to describe them. Ill describe the practices and then discuss how they are best used and how they characterize the Extreme Programming process.

Whole Team

The Whole Team practice calls for all the stakeholdersdevelopers, managers, customers, and usersto form a single team. The practice calls for the team to work together and to be together psychologically and even physically. The ideal situation is to have the whole team together, in one room, to do their work. ^[1]

The Whole Team practice was originally called On-Site Customer to reflect the special importance of a tight connection between the people who need the software, customers and users in the XP Customer role, and those developing it, developers and managers, whom we call Programmers. When customers and programmers are together, information flows freely and rapidly . Perhaps even more important, working together engenders trust and cooperation between these two halves of one project.

This practice, as you can see, supports the values of simplicity, communication, and feedback. It enables the team to use conversation instead of needing so much written material, and because the team members are together, their conversations can be as frequent as needed to keep everyone aligned.

Planning Game

The XP planning practices are called the Planning Game to make planning less frightening and to remind us that planning is an activity that works best if we do it willingly and often. XP plans are always produced by the Whole Team, never by a single individual either inside or outside the team. The practices combine the special knowledge of everyone on the team. Customers understand priorities and needs, managers understand time and money budgets , and programmers understand how to build things and how long it will take.

The XP Release Plan lays out a picture of the whole project. It looks at all the known requirements in sufficient detail to associate an estimate with each desired feature, or story, as we call the features. With estimates in hand, customers and managers can put together the best possible schedule given priority and budget. This plan is, of course, subject to revision as the whole team learns more about all the variables : feature definitions, priorities, actual costs, and changing budgets. An XP Release Plan can give an increasingly accurate picture of what is really going to happen. Wise teams update their Release Plans very frequently.

The XP Iteration Plan plans the next iteration. XP teams develop software in short time-boxed periods called iterations, typically spanning one or two weeks. In each iteration, the team plans, builds, and delivers tested new features to the customer. Yes, features are delivered starting with the very first iteration. Theres no three months to set up the framework in XP, and just how we go about delivering with the first iteration is the real subject of this book.

At the beginning of each iteration, the Iteration Plan is produced. At first, it can be difficult to know how much we can get done in an iteration, but because we repeat the planning process every week or two, we quickly get quite good at it. The customer, based on the programmers estimates of cost and on the teams observed speed of building features, selects the feature stories to be built. The team puts together a simple plan to get these stories done and then builds, tests, and delivers the software.

These XP planning practices are quite simple. They focus on communication of requirements stories and on feedback about the speed and quality of our implementation. In addition, the customers get good feedback on the quality of their decisions, by seeing the actual results of their requests in tested, running software.

Small Releases

XP teams focus on small releases of tested, running software. With every iteration, the team delivers proven software to its customers. Beyond that, however, we put the software in the hands of real end users as frequently as possible. If an XP project were to run for a year, we would like to ship production versions four or more times during that period.

This practice provides important feedback to stakeholders on how well the team is progressing. Placing the product in real users hands also provides important feedback on the quality of requirements stories and on priority decisions.

Customer Acceptance Tests

Although requirements stories are written on cards to serve as planning tokens, and although stories are explained in many conversations between programmers and the on-site customers, requirements in XP have a third critical component: confirmation. The customer confirms that every story is correctly understood and implemented by defining one or more automated Customer Acceptance Tests (also referred to as customer tests throughout this book). Lets underline these points. An XP story includes three aspects: card, conversation, and confirmation. And the story is done when the Customer Acceptance Tests run.

This practice provides important feedback to the customers about the quality of the teams workand important feedback about the quality of the customers own tests. The customer tests communicate and document the precise requirements in an unambiguous and verifiable way. Seeing the Customer Acceptance Tests coming on line and continuing to work gives the entire team confidence that things are going well and provides the courage to continue.

Simple Design

As a new program comes into being, it starts out small and grows over time. We want the design of the program to be good always, and we observe that a small programs good design can and should be much simpler than that of a larger program. Because we are building the program incrementally, shipping new and improved versions every couple of weeks, we start with a simple, good, and sufficient design for the small early versions and we grow and improve the design as we add capability to the program. The result is that our design investment is spread over the whole life of the project, rather than loaded at the front. Because of this, we can spread the delivery of features over the life of the project as well, instead of loading feature delivery towards the end. We can even deliver the most important features early in the project lifetime. This practice improves the return on the project investment, and it gives our stakeholders great feedback and courage about the project. We focus on keeping the program as simple as possible but no simpler. We use the rapid feedback of XPs short iterations to improve the design.

This book is about this process. It explores how we can begin a project knowing very little, begin with a simple design, and keep our design good as we grow the program.

Pair Programming

Extreme Programmers write their production code with two programmers sitting side by side at the same machine. This practice provides immediate code review for every line of code, it improves the design every step of the way, it helps us maintain energy and momentum, and it helps us maintain the discipline to work in the most effective way we know how.

Most programmers have worked together on hard or interesting problems, and usually they find it productive and beneficial. Extreme Programmers work together all the time and gain the benefits all the time.

The practice of pair programming provides immediate feedback on the quality of our work. It helps us communicate the design ideas, and it helps us upgrade our skills through sharing. It gives us courage to work on parts of the code we might otherwise be afraid to touch.

In this book, which is mostly a one-person effort, I didnt always get to pair program. This means youll get a clear look via my efforts in this book at the effects of working with someone else versus working alone.

Test-Driven Development

Because we are growing the program as we go, because we are committed to improving the design, and because we must ship working software so frequently, we need great confidence that our new code, and our design changes, work as we intended them to. We cannot afford to have some design change break existing functionality or slow down the adding of new features.

Extreme Programmers accomplish this using Programmer Unit Tests (also referred to as programmer tests throughout this book), which we write as we go. We write most of the tests one at a time, immediately before adding the feature being tested. When, as inevitably happens, we do find a defect after the fact, we write new tests that first show that the defect exists and that then confirm we have the problem fixed. The existence of this growing family of tests helps us communicate what the code is supposed to do and how to use it, and it gives us feedback as to whether the code does its job correctly. The automated tests give us concrete feedback, showing that our changes havent broken anything, and they give us the courage to make the changes needed to keep the program alive and growing.

In this book, youll see how we write these tests and how they give us courage. Youll also see what happens when we slip and dont write all the tests we should!

Design Improvement

If were going to start small and simple and to grow the program while keeping its design good, we must improve the design as we go. Extreme Programmers do design improvement using refactoring, a highly disciplined technique for improving the design of existing code. The definitive book on this subject is Martin Fowlers Refactoring: Improving the Design of Existing Code (Addison- Wesley, 1999), and wise programmers everywhere, extreme or not, will study it and learn its lessons.

Refactoring is not about churning the code. Its about keeping the design clean as requirements are added such that the program remains viable alive throughout development.

The refactoring practice supports the simplicity of the design and improves the ability of the code to communicate its design and intent. Continuous refactoring on an XP project is safe because we have our extensive automated tests to give us feedback on our changes and to gives us the courage to continue.

In this book, youll see our simple programs design improve through refactoring, and youll get a sense for the power of the technique and the pitfalls in its use.

Supporting Practices

The eight practices described so far include the four that help with the customer/programmer interface: Whole Team, Planning Game, Small Releases, and Customer Acceptance Tests. I call these the Circle of Life. The other four practices make up the central programming cycle, which might be called the Circle of Code: Simple Design, Pair Programming, Test-Driven Development, and Design Improvement. There are five more supporting practices that we need to consider briefly .

XP teams practice Continuous Integration . The program is always integrated, always ready to go. XP teams say that ^sb daily builds are for wimps. (Througout this book, the ^sb superscript indicates the beginning of what Im calling a sound bite. See the Sound Bites chapter at the back of the book for more on these.) The best XP teams, even quite large ones, integrate and build the entire system many times per day. This practice provides feedback on the quality of our work, and ensures that we will communicate frequently about what were doing.

Extreme Programmers practice Team Code Ownership . Any pair of programmers is empowered to improve any code at any time. This practice is safe because of our many tests and easy to do because we pair program, learning new areas of the system all the time. The practice provides a simple way to put resources where theyre needed, provides a platform for communicating design ideas across the team, and gives feedback to us all so that we can benefit from everyones ideas.

XP teams evolve a Coding Standard . Because we work together all the time, a standard is inevitable. Well have to agree on a few things, like where to put the curly braces, but most of the standard emerges as a natural result of working in pairs and owning all the code as a team. The coding standard adds simplicity to our process by allowing flexibility and by settling many details. It improves our ability to give feedback by keeping the form of all code familiar. It helps us communicate through the code, and it gives us courage to contribute to any area needing our help.

XP teams use a Metaphor or System of Names to provide a common language for talking about the design of the program. Often a simple metaphor can help us focus on how the system works: Its like a swarm of bees that go out on the Web and bring information back to the hive. Or Its like a manufacturing line that manufactures checks instead of cars . Even if we dont have an evocative metaphor, we develop a common terminology that helps us communicate quickly and effectively.

XP teams work at a Sustainable Pace . We do not kick way back sometimes and work massive overtime at other times. We strive to go as fast as possible and no faster. While well certainly put in extra hours in an emergency, we are very sensitive to the fact that an over- tired team is a stupid team and stupefied programmers write defective programs. Worse yet, they write those defective programs slowly! We work hard, rest well, and come back to work refreshed. Sustainable Pace is not a license to slack off; it is a demand that we always make our best possible forward speed. This practice provides consistent velocity feedback, which communicates how were doing to our customers and other stakeholders. It requires that we know what our best pace is and that we have the courage to stick to it.

^[1] When we say ideal, we mean it. Recent studies at the University of Michigan found that teams work ing physically together were two times as effective as those working apart.