1. Conclusion
1.1. Good
1.1.1. Coding Standards
1.1.2. Continuous Integration
1.1.3. Pair programming
1.1.4. Collective Ownership
1.1.5. Simple Design
1.1.6. Unit Testing
1.1.7. Sustainable Development/40 hour weeks
1.2. Bad
1.2.1. On-site customer
1.2.1.1. No onsite customer under the conditoins of producing Packaged Software
1.2.2. Metaphor's
1.2.3. The planning game
1.3. Maybe
1.3.1. Small Releases
2. Practices
2.1. Coding Standards
2.2. Small Releases
2.3. Metaphor's
2.4. Continuous Integration
2.5. The planning game
2.6. Pair programming
2.7. Collective Ownership
2.8. On-site Customer
2.9. Simple Design
2.10. Unit Testing
2.11. Refactoring
2.12. Sustainable Development/40 hour weeks
3. Stake Holders
3.1. Project Managers
3.1.1. needs
3.1.1.1. Project to be completed within budget
3.1.1.2. product to satisfy consumers
3.1.1.3. product to be bug free
3.1.1.4. Good development team
3.1.2. Risks
3.1.2.1. Programmes quit
3.1.2.2. Project overruns budgeted time
3.1.2.3. Feature/Scope Creep
3.1.2.4. Project does not ship on time
3.2. Shareholders
3.2.1. needs
3.2.1.1. increase in share price
3.2.1.2. Company to release good software
3.2.2. Risks
3.2.2.1. Decrease in share price
3.2.2.2. company goes bankrupt
3.3. Consumer
3.3.1. needs
3.3.1.1. Software than is fit for purpose
3.3.1.2. Value for money
3.3.1.3. Extenable software
3.3.2. risks
3.3.2.1. Software not fit for purpose
3.3.2.2. Softare cant be adapted for purpose
3.3.2.3. Software out of warrenty/support
3.3.2.4. Users dont like the software
3.4. Company Managers
3.4.1. needs
3.4.1.1. increase in sales of product
3.4.2. risks
3.4.2.1. competition in the market
3.4.2.2. drop in sales
3.5. Developers
3.5.1. needs
3.5.1.1. Good working atmosphere
3.5.1.2. Job satisfaction
3.5.1.2.1. Unit Testing
3.5.1.2.2. continuous integration
3.5.1.2.3. Sustainable Development/40 hour weeks
3.5.2. Risks
3.5.2.1. Job security weaken'd from ununiqueness
3.5.2.1.1. Pair programming
3.5.2.1.2. Collective Ownership
3.5.2.1.3. Simple Design
3.5.2.2. stress from lots small releases
3.5.2.2.1. Small Releases
3.5.2.3. arguing with partner
3.5.2.3.1. Pair programming
3.5.2.4. Fault exposure and ego deflatution no sence of unique ownership
3.5.2.4.1. Collective Ownership
3.5.2.5. inexperiance in XP practices
3.5.2.6. Developer Burnout
3.5.2.6.1. Sustainable Development/40 hour weeks