Extreme Programming Principles

23 Oct 2014

The principles of Extreme Programming are intended to be a bridge between its values and practices, because XP values are too abstract to be translated directly into actions.

For example, test-driven development is a practice, feedback and communication are its values, and mutual benefit is the principle: I write tests to help me guide my development process, and at the same time I'm leaving a suite of automated tests that will help future programmers understand and change the system.

The Extreme Programming principles are meant to help you understand the reason behind its practices, and they should serve you as guide if you need to come up with your own practices for your particular situation. I share with you a list of the principles that have been the most useful to me:

  • Humanity

    Software has sometimes cold environments because you don't interact as much with other people, compared to sales for example. Don't forget there's people behind our work, with needs such as safety, accomplishment, belonging, and growth. Becoming aware of such needs and working towards fulfilling them will yield greater results for all involved.

  • Economics

    Do valuable work, someone is paying for it. Ensure you're helping the business meet its goals, don't just aim for technical wins.

  • Mutual Benefit

    Software development is a team-player activity. Keep the interests of your team and your business in mind. Your actions should aim to provide benefits for everyone.

  • Improvement

    We're not perfect, we don't know everything and we never will, but we certainly can become better over time. Nobody expects you to be pefect, do the best you can do evey day, and strive to do better tomorrow.

  • Reflection

    Think about how and why you're doing your work. Analyze your decisions, your actions, and what led you to succeed, or to fail. Learn from your mistakes and seek feedback often.

  • Failure

    If you don't know how to succeed, sometimes it's worth risking a failure. Instead of freezing or wasting time thinking over and over what might be best solution, take baby steps and even if you fail at first you'll likely succeed in the end.

  • Quality

    Don't let your quality standards get out of line for the sake of urgency or money. Negotiate on scope, since usually time and costs are fixed. High quality over time results in constant or faster productivity. Bad quality slows projects down to the point where they consume many more resources or fail.

References

  • Extreme Programming Explained: Embrace Change (2nd Edition).