Guideline: XP Environment

No process is an island. In other words, you can't expect to just take a process or process elements off a shelf and use them without regard to their context.

XP has certain key requirements of the "environment"; the physical, organizational, and business setting where it will be applied.

One key aspect of XP is a strong focus on communication. To communicate effectively, a team should have as few physical barriers to each other as possible. The ideal XP programming environment is an open workspace filled with tables and room for pairs of people to work together and maintain contact with their peers. For more details, see the open workspace guideline.

Uniform Toolset

XP works best when there are no artificial impediments to getting and giving help. If you have an open workspace with five computers for production coding and each of them has a wildly different set of tools, some people will gravitate to the machines that have the tools they like and feel uncomfortable moving to the machines that have unfamiliar tools. Think about your own experiences. Do you feel hindered working in an unfamiliar IDE? How much does that impede you when someone asks for your help. If, as a team, you adopt a uniform set of tools and keep your development machines homogenous, you are making it far easier for people to give and receive help.

Dedicated Build Machine

In XP, there are many different ways to do builds. However, the primary constraint is that all unit tests are run prior to checking in any production code. In most situations, the easiest way to accomplish this is to have a dedicated build machine. You can check in your code and trigger a build across the network or walk to the build machine and run the build. Either way, having a dedicated machine gives you the advantage of having a common, pristine environment for your builds.

Version Control Tool

All software projects need version control tools; however, in XP we place a premium upon their usability. The ability to be able to check out code without locking it is also valued. When a team writes pervasive unit tests and practices collective code ownership, locking code for revision is often too pessimistic. It creates unncessary bottlenecks.

Organizational Requirements

Organizations adopting XP should be able to dedicate someone to act as the customer for each XP team. The customer role in XP is critical. If the person who is acting as the customer has other responsibilities, it is best if those responsibilities are subordinate to being available to the rest of the team.

In addition to having an available customer, organizations practicing XP should allow teams to be self-sufficient. In organizations where many functions are supported by different groups (configuration management group, deployment group, QA), the different functions can impede development if there are not mechanisms to allow each team to do what it takes to finalize its iterations without waiting for other teams.

Business Requirements

XP works best in situations where organizations can take advantage of variable scope. If a business creates a fixed scope contract with a fixed end date, it can be hard to discern how long it really takes for a team to sustainably develop good software.

People in the organizations look at the schedule rather than the velocity data that XP produces. The result is all too predictable. Software may be delivered on time, but it may also be buggy and a poor platform for future development. In XP, we recognize that each team has a particular speed at which they can reliably develop software. That speed varies from team to team. If a team is pushed faster than that speed, the results are often disasterous.