You might be familiar with some of the XP practices, such as test-first programming, incremental design, continuous integration, etc. In order to get the most out of each practice, it’s very important to understand the values and principles behind the practices. Creating tests for the sake of fulfilling a job requirement can seem painful and a waste of time, versus if you understand that you are leaving documentation for yourself and other developers, and also a suite of tests to give you confidence to modify the system, it’s a much better reason to do and enjoy TDD.

The XP practices are divided into primary and corollary. The primary practices are meant to be the starting point because they give you immediate results.

Some of the primary practices I’ve found easier to integrate into our workflow are:

• Sit together

  Encourage conversation by sitting together. XP recommends an open work space for you and your team, but If you’re not used to it you can get there eventually. The point is increasing the amount of face-to-face interactions. This also works for distributed teams.

• Energized work

  We’ve all been there, too many extra hours of work for a long period of time and you’ll burn out. Get enough rest, and work as much as you can while being productive, otherwise it’s best to call it a day. You might think it’s ok to spend extra hours to finish a project or meet a deadline, but you need to work at a sustainable pace. Unrealistic deadlines can’t be met, and it’s not your fault. Work the best you can at a constant, predictable pace, and let other people manage their expectations.

• Weekly cycle

  Get used to have a meeting at the beginning of every week to plan a week’s worth work. XP recommends writing tests for the features you expect to get done, and spend the rest of the week making them pass. If you notice you’re not going to make it, adjust your plan and let go of the less important tasks.

• Slack

  This one is tricky because most managers won’t be happy if you tell them “Hey, we need to add 3 extra months in case something goes wrong”. Plans can give you a pretty good idea of the challenges involved when solving a given problem. They also help you understand tasks dependencies and in what order to tackle them. Plans are a necessary evil. You need to do some planning in order to start working on a problem, but if you try to plan too much ahead they become only as good as guesses, and they may be used against you when you don’t meet a deadline. XP recommends you include some minor tasks to drop in case you get behind schedule. If you commit to more than you can handle, you’ll start ditching your best practices for the sake of meeting a deadline and fulfilling the expectations you set, and if you repeat this behavior over and over you’ll end up with an inferior and unmanageable product.

• Test-first programming

  Testing first is a form of guiding design. When you’re about to tackle a technical problem, you need to think through what you’re trying to solve, and laying out a suite of tests can help you get a better idea of where you want to go. The challenge is writing the right tests, which are simple enough to get you moving in the correct direction, and let you take baby steps to arrive at a complete solution.

• Incremental design

  One of my favorite practices. There is only so much you can plan ahead that will actually be useful. Work in small iterations, grow your design as you implement and understand the system’s needs. Do only what’s absolutely necessary and provides the most value. Use the feedback you get to make better and more informed decisions of what to implement.

I found these practices very easy to integrate into my daily workflow. More practices are covered in Kent Beck’s book Extreme Programming Explained, 2nd Edition. I highlight the edition because Kent applied XP practices to his own book, and the 2nd edition seems to be almost a complete rewrite of the first.