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
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.
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.
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
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.
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.
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.