Extreme Programming Explained: Embrace Change by Kent Beck, Cynthia Andres
My rating: 4 of 5 stars

Values

• Communication – important for creating a sense of team and effective cooperation
• Simplicity – eliminating unneeded work the simpler things are the easier communication is
• Feedback – this is a vial form of communication contributing to simplicity
• Courage – to speak the truth, pleasant or unpleasant, fosters communication and trust; to discard failed solutions encourages simplicity; and seek real, concrete answers in feedback.
• Respect – the contributions of each person on the team needs to be respected, I am important and so are you
• Team values – this is adding extra values which the team feel are important and by having them explicit means they are important e.g. safety, security, predictability, quality-of-life etc

Principles

• Humanity
  • Basic safety – freedom from hunger, physical harm, threats, fear of job loss.
  • Accomplishment – to be able to contribute
  • Belonging – to identify with a group from which they receive validation and accountability
  • Growth – to develop skills and perspectives
  • Intimacy – to understand and be understood deeply by others
• Economics – delivering bussiness value, meeting business goals and serves bussiness needs.  For software development the economics are that the sooner there is delivery the sooner there is value.
• Mutual Benefit – help me now, in the future and the customer
  • Automated tests – help design and implement better solutions today, in the future this benefits people maintaining the system
  • Refactor – removes additional complexity giving me satisfaction today and fewer defects, in the future it makes the code easier to understand
  • Names – makes code coherent and explicit which speeds up my development, in the future the cleaner code is better for new programmers.
• Self-Similarity – try to keep the same structure even at different scales, such as the processes you do in a week you might do at a larger scale every month (e.g planning, demo etc)
• Improvement – things are never perfect, starting with something and evolving it in the right direction to provide a solution which is good enough
• Diversity – this brings creativity and different perspectives to the problem
• Reflection – exposing mistakes and learning from them after the action
• Flow – aiming to produce value quickly with new features flowing through the team at the highest possible rate
• Opportunity – taking each problem and using it as an opportunity to learn
• Redundancy – this might be needed to ensure the product is correct, it should not just be removed immediately but work should be done to improve the process until it is not needed and then removed
• Failure – this could be the cheapest way to learn given the option for weeks or research compared to a similar time trying things the latter might result in multiple failures but result in a good solution quicker
• Quality – quality can not be cut to save time or cost, for software quality needs to be improved to identify defects early, enable new joiners to get up to speed etc.  If time or cost need to be cut then feature scope is the only leaver that can be pulled.
• Baby Steps – and grow in the right direction rather than a big bang approach
• Accepted Responsibility – a person should be responsible for the whole feature from estimate it, designing it, implementing it and testing it.

Primary Practices

• Sit Together – to boost communication
• Whole Team – all the skills needed to complete the project, everyone in it together
• Informative Workspace – such as whiteboards, stories on the wall etc
• Energised Work – actually getting quality work done, not just clock time – if you are unable to sustain working more then stop working rather than burning yourself out for the next few days
• Pair Programming – keep each other on task, brainstorm refinements, clarify ideas, support each other, hold each other accountable for the team’s practices
• Stories – plan units of customer-visible work and estimate them as soon as they are written, the estimate gives more visibility for prioritisation
• Weekly Cycle – plan the work a week at a time, review progress, select stories and break them down into tasks
• Quarterly Cycle – reflect on the team, the project, its progress and align with the larger goals.
• Slack – it is important to meet your commitments to build trust with stakeholders so including minor tasks which can be dropped if needed could be beneficial
• Ten-Minute Build – produce the shortest feedback time possible and certainly less than ten minutes aka the time to get a coffee
• Continuous Integration – ideally in a synchronous way get the whole system built, integrated and deployed (even if only into a test environment)
• Test-First Programming – write failing tests first so that you can prevent scope creep, improve the loose coupling and high cohesion of the code, improves team trust and produces a rhythm focused on delivery
• Incremental Design – regularly reviewing the design and then allowing for refactoring so that the design emerges as more is learnt about the way things need to work.

Corollary Practices

• Real Customer Involvement – this is to increase the value produced by the system
• Incremental Deployment – when replacing something gradually take it over small piece by small piece as early in the project as possible
• Team Continuity – keep effective teams together and move them to other projects
• Shrink Teams – try to get the team as small as possible to deliver the work required
• Root-Cause Analysis – the aim is that when an issue occurs that it is not just fixed but a similar type of issue can not occur again
• Sharing Code – the team should own the code so anyone on the team can make changes to it
• Code and Tests – should be the only permanent artifacts other documentation should be generated from them
• Single Code Base – there should only be one code stream and short lived branches
• Daily Deployments – getting the code to generate value as soon as possible but this needs the support of sufficient tests etc which take time to build up
• Negotiated Scope Contract – have shorter contracts with fixed time, cost and quality but negotiable on scope
• Pay-Per-Use – this is a great feedback for which features are actually used, should be developed further or removed