Extreme Programming (XP)

Extreme Programming (XP) is a core agile method that focuses primarily on construction-oriented practices. Although XP’s practices appear straightforward on the surface, many of them require not only technical skill but also significant discipline on the part of practitioners. The following XP practices^[5] are adopted by the DAD process framework:

^[5] Once again, in some cases the practice name is in the format XP name (DAD name).

• Coding standard (development guidelines). Team members should follow established coding guidelines and standards. This includes recommended patterns and mechanisms to ensure consistency, reduce defects, and simplify readability and maintenance. DAD explicitly extends this to all types of development guidelines, including data guidelines, user interface standards, architectural guidelines, and security guidelines to name a few.

• Collective ownership. Every team member is allowed to view and edit another team member’s code or any other project artifact. This encourages transparency and accountability for work quality. A shared understanding and ownership of the code base reduces the risks related to people leaving the team. All team members are better prepared to maintain or improve any code in the system and will speed up the development process because any team member can implement any new feature or fix any defect. Note that pair programming facilitates the shared understanding and ownership of the code.

• Continuous integration. Team members should check in changes to their code on a frequent basis, integrating the system to ensure that their changes work, so that the rest of the team is always working with the latest version of the system. The integration effort should validate whether the system still works via automated regression tests and potentially even through dynamic and static code validation.

• Customer tests (acceptance test-driven development). Detailed requirements are captured on a just-in-time (JIT) basis in the form of acceptance tests (also called story tests). See discussion of test-driven development (TDD) later in this section.

• Refactoring. A refactoring is a small change to something to improve its design and thereby make it easier to understand and to modify. Therefore a code refactoring is a simple change to your code, a database refactoring is a simple change to your database schema, a user interface (UI) refactoring is a simple change to your UI, and so on. The act of refactoring enables you to evolve your work slowly over time, to take an iterative and incremental approach to development.

• Pair programming (non-solo work). Pair programming is a practice where two programmers work together on the same artifact. One programmer types the code, while the other programmer looks at the bigger picture and provides real-time code review. Pair programming is an example of non-solo work, as is Agile Modeling’s practice of modeling with others, where two or more people work together to accomplish a task. Non-solo work provides opportunities for people to learn from one another, leads to higher quality as defects are often spotted as they’re being injected into the work, and spreads knowledge of the work artifacts across a greater number of people (this is particularly true when you switch work partners regularly).

• Planning game (release planning and iteration planning). The purpose of the planning game is to guide the product into successful delivery. This includes high-level release planning to think through and monitor the “big issues” throughout the project as well as detailed just-in-time (JIT) iteration planning.

• Simple design. Programmers should seek the simplest way to write their code while still implementing the appropriate functionality. This increases productivity. Note that periodic refactoring may be required to ensure that the design remains simple and of high quality.

• Small releases. Frequent deployment of working software into production is encouraged. This functionality should be delivered in increments that provide the greatest value to the customer. Frequent deployments build confidence in the team and trust from the customer. DAD takes this one step further to focus on delivering working solutions, not just working software.

• Sustainable pace. Although overtime is sometimes needed on an irregular basis, it is not sustainable over long periods of time and can reduce morale, productivity, and quality substantially. The team should be able to sustain an energized approach to work at a constant and gradually improving velocity.

• Test-driven development. In TDD the first step is to quickly code a new test, basically just enough code for the test to fail. This could be either a high-level acceptance test or a more detailed developer test (often mistakenly referred to as a unit test). Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new test. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed). When you write a test before you write the code to fulfill that test, the test not only validates at a confirmatory level that your code works as it is expected it also effectively specifies your work in detail on a just-in-time (JIT) basis.

• Whole team. Team members should collectively have all the skills required to deliver the solution, although in Chapter 5, “Forming Disciplined Agile Delivery Teams,” we’ll see that sometimes agile teams need to bring specialists in for short periods to address specific and unique issues. Furthermore, the stakeholder(s), or their representatives such as product owners or business analysts should be available to answer questions and make decisions in a timely manner.