XP Principles

 

XP Principles help translate its values into practices. The principles are particularly important when some of the practices may need to be modified to suite a given environment.

Kent Beck (1) describes 14 principles of XP.

  1. Humanity : XP is designed to meet the basic human needs of safety (freedom from fear), accomplishment, belonging, growth, and intimacy (to be deeply understood and understand others). An example is of this is shown in XP’s emphasis on face-to-face communication and colocated teams.
  2. Economics:  XP is based on 2 economic concepts: first, the time value of money and secondly, the value of options.
    1. Time value of money: ‘A dollar today is more valuable than a dollar tomorrow’. That is, money can earn interest, so the sooner money is received the more its worth. Applied to software – software is more valuable if it  earns money or provides value sooner and delays expenses till later. For example, the XP concept of frequent releases aims to get the customer deriving value from the software sooner.
    2. Value of Options: A financial option involves the right (but not the obligation) to do something in future. Options are considered valuable in the presence of uncertainty (uncertain customer requirements, technology direction etc) because they minimise risk in the case of adverse circumstances. Applied to software, this involves delaying decisions to the least responsible moment (Poppendieck, 2003) for example in the XP concept of incremental design.
  3. Mutual Benefit – every activity should benefit all concerned. A practice should not cost one person and benefit another. For example, developers do not usually love writing extensive internal documentation. Writing a reasonable amount of documentation supplemented with extensive automated tests, well named classes, methods and functions may be more beneficial to developers.
  4. Self-Similarity: Many problems can be solved by simply copying the structure of a different solution into a different context and scale. For example the “Red-Green-Refactor” rhythm of automated tests can be applied both at unit-test level and at larger system test level.
  5. Improvement: There is no perfect process or design – you can always continuously improve. Continuous improvement leads to excellence.
  6. Diversity: Software teams need to bring together a diversity of skills, attitudes and perspectives to best explore multiple ways to solve a problem. A software team made of individuals with very similar skills and attitudes may not be as effective at exploring creative solutions. Diversity brings conflict in the sense that there may be multiple competing solutions to a problem. These solution ideas need to be respected and discussed. The concept of Whole Team, and iteration planning help discussion to explore the best ideas.
  7. Reflection: Create time to think about how you are working, and why. Analyse success and failure. Learn from them. The end of each iteration cycle is a good time to reflect, but reflection should not be limited to this. Reflection can be done at the end of the day after pair-programming, at shared meals and coffee breaks, and informal settings. Reflection can be an opportunity to explore how one feels about the project, and think about and gain insight from why those feelings are occurring.
  8. Flow: As opposed to large batches of work, XP is biased towards delivering a continuous flow of value by doing parts of all stages of development continuously.
  9. Opportunity- See problems as opportunities
  10. Redundancy – Have multiple solutions to the challenges you face in your development process. If one solution fails, the others can help resolve the issue.
  11. Failure – When the definite solution to a problem is not known, try different proposals, fail fast and learn from the failure to gain insight.
  12. Quality – Always strive to keep quality high.
  13. Baby Steps – Trying to make large changes all at once can be very challenging and involve more risk- especially when it involves people. Consider breaking the change down into small ‘baby’ steps. This provides the opportunity to reflect on the results after each step. Aborting the change if things are not working out involves lower overhead.
  14. Accepted Responsibility – Trying to assign responsibility to people who are not prepared to accept it can cause misalignment. Let people chose what they are responsible for so that they can learn from the feedback in carrying out that activity.