# Extreme Programming Explained 2nd - Chapter 5. Principles 1. Humanity 2. Economics 3. Mutual Benefit 4. Self-Similarity 5. Improvement 6. Diversity 7. Reflection 8. Flow 9. Opportunity 10. Redundancy 11. Failure 12. Quality 13. Baby Steps 14. Accepted Responsibility ## Summer: **1. Humanity** Software development should acknowledge and serve human needs such as safety, accomplishment, belonging, growth, and intimacy, balancing individual and team requirements to foster well-being and effectiveness. **2. Economics** All software work has a cost; practices should maximize real business value, prioritizing work that delivers the most timely and valuable results and focusing on options that keep future possibilities open. **3. Mutual Benefit** Prefer solutions and practices that benefit all parties now and in the future, rather than compromising one group for another, as sustainable success relies on maintaining good relationships and shared benefit. **4. Self-Similarity** Design and development structures that work well at one scale often work at different scales; recognize productive patterns and reuse them as appropriate, being alert to context-specific adjustments. **5. Improvement** Strive for continual improvement, not unattainable perfection—get started, deliver, and then refine processes, designs, and outcomes through regular feedback and learning. **6. Diversity** Effective teams require a diversity of skills, perspectives, and attitudes; this diversity enables creative problem-solving and resilience, even if it sometimes brings conflict that must be resolved constructively. **7. Reflection** Teams should actively reflect on how they work and why, learning from both data and emotion, to continually hone practices and develop insight that drives excellence. **8. Flow** Aim for a smooth, ongoing flow of valuable software by delivering small increments frequently, integrating and deploying often, and avoiding the risks of "big bang" integration or delivery. **9. Opportunity** See problems as opportunities for positive change, leveraging challenges as a chance to improve systems, skills, and relationships instead of merely surviving difficulties. **10. Redundancy** For critical software problems (such as defects), use multiple, overlapping strategies to prevent failure; redundancy, when purposeful, increases reliability and trustworthiness. **11. Failure** Don’t fear failure—when the best approach is unclear, trying different solutions (and sometimes failing) is often the quickest way to gain needed knowledge and achieve success. **12. Quality** High quality should not be sacrificed for schedule or cost; maintaining and improving quality generally accelerates delivery and leads to more predictable outcomes, as well as personal pride in the work. **13. Baby Steps** Big changes should be approached through many small, rapid steps, as incremental change is easier for people to adopt, and small experiments keep risk and disruption low. **14. Accepted Responsibility** Responsibility must be voluntarily accepted, not forced; only when a person accepts responsibility for a task do they also gain the authority and accountability needed for effective work. --- Beck, Kent; Andres, Cynthia. Extreme Programming Explained: Embrace Change (pp. 49-64). Kindle Edition.