XP divides its practices into primary and corollary, their purpose is to help you achieve excellence in software development. Primary practices can be adopted immediately and yield instant results, corollary practices on the other hand require mastery of at least a few primary practices. For example, daily deployment is useless if your team ships code filled with errors. You must have a decent level of experience with the practices related to creating high quality code before you can deploy to production every day.

• Real customer involvement

  Get feedback directly from the customer at least once a week. The point is to avoid and reduce wasted development effort by making sure we’re on the right track, and always adding value.

• Incremental deployment

  Replace existing systems one step at a time. Big deployments are a high-risk bet and rarely work. Instead, swap pieces of functionality or find a way to run both systems in parallel. Users will probably have to duplicate some effort, but consider it the price to pay for ensuring the project succeeds.

• Team continuity

  Teams that are effective and trust each other should work together. If you ignore the value of the relationships that develop it could result in reduced productivity. Encourage a reasonable amount of rotation to spread knowledge and experience across the company.

• Shrinking teams

  Effective teams will get better over time, and eventually do more in less time. Keep the workload constant and reduce the team size once they’ve eliminated enough waste and improved their workflow.

• Root-cause analysis

  Don’t put a “band-aid” every time your team makes a mistake. Instead, learn from it and why it happened, and think of ways to ensure the same kind of mistake won’t ever happen again. This analysis often uncovers problems at a higher level of the company, which result in a change/fix of a broken policy or practice.

• Shared code

  Anyone in the team should be able to improve any part of the system. Before attempting to do this the team should have a deep sense of responsibility and pride of their code.

• Code and tests

  Code and tests are the only permanent and accurate description of the system. They are the most important form of documentation because they’re always up to date, and should be treated accordingly.

• Single code base

  The team should strive to work on a single code base and avoid long-lived temporary branches. Different versions of the code often result in conflicts and duplicated efforts.

• Daily deployment

  The gap between development and production code should be kept small by deploying frequently. The larger this gap is, the larger the risk of failure when you deploy. Small, iterative deployments also result in faster feedback for the business to make better decisions.

• Negotiated scope contract

  In software projects, time and costs are usually fixed. Add quality to that list and you can negotiate on scope. The reason why quality should be non-negotiable is because as soon as you drop it, the project starts to deteriorate. A few weeks or months in and the system becomes unmaintainable. The risk of failure is high for projects with spaghetti codebases, where even adding small features has a high cost. Avoid long contracts and commit to smaller releases by signing a set of short contracts. As the project moves forward and you get feedback from customers, you want to be able to respond to change and integrate new features if needed instead of seeing yourself forced to work on old requirements because the contract says so.