Transitioning to XP or The Fanciful Opinions of Don Wells

1. Transitioning to XPorThe Fanciful Opinions of Don Wells

2. XP Through the Ages • The illusion of making promises to the customer and then keeping them • More of what helps, less of what hinders • Dials to ten • The short list • The 12 practices • Agile methodologies

3. Are you doing XP? (The short List) • Paradigm - Do you recognize change as the norm? • Values - Do you work toward communication, simplicity, feedback, and courage • Power sharing -- business makes business decisions and development makes technical decisions • Distributed responsibility and authority -- people make commitments they will be accountable for • Optimizing process -- Are you aware of what doesn’t work? Are you trying to fix it?

4. The 12 Practices • The planning game • Small releases • Metaphor • Simple design • Testing • Refactoring • Pair Programming • Collective ownership • Continuous integration • 40-hour work week • On-site Customer • Coding standards

5. Agile Methods • Less emphasis on process, more emphasis on team work • Greater emphasis on running code • Work with your customers • Greater emphasis on enabling change • Fix the process when it breaks

6. Transitioning to XP • Take care of your customer relationship first! • Take stock of where your process is now. What is good about it? • Change the process based on your findings • Develop a set of values and goals • Look at the mechanics of your process. Can you get more from less? • Generalize about what you have

7. What Is So New? Attitude! • Team work, real team work • Testing as a part of development • Less documentation

8. Team Work, Real Team Work • Stand up meetings • Pair programming • Collective Code Ownership • The customer is here with us • Tell the truth

9. What Makes a Team • Everyone contributes at their own level • Everyone is in the yoke • Everyone is of equal value to the project’s success • If you miss something, your team will not

10. Testing As a Part of Development • Get your hands on the unit testing framework and refactor it, make it your own. • Unit tests help you decide what the public interface should look like. • Unit tests help make the code more testable and thus more reliable. • The coverage you need for legacy code is not as much as you think, black box tests boost your coverage quickly.

11. Less Documentation • Planning instead of a plan • User Stories instead of requirements • CRC cards instead of design documents • Tests instead of specifications • The code speaks for it self instead of comments • Metaphor instead of class diagrams • You still need to create a User Manual

12. User Stories • Stories must be backed up with a conversation • Separate business and technical decisions • Knowledge doesn’t fit on paper • “These customers don’t know what they want” • You must dig deep and ask questions

13. What Makes it So Hard? • Social activities (communication) • Rapidly spinning tight loops (feedback) • Subjective criteria for success (simplicity) • No fall back excuses (courage)

14. Social Activities (Communication) • Pair programming • CRC cards • Talking to the customer • Stand up meetings • Iteration planning • Release planning

15. Starting Pair Programming • People who are willing • Equal level • Mix everyone with everyone else • Have a teacher • You can teach programming, and you can teach pair programming, but not at the same time

16. Three modes of Pairing • Mentor-student • Side by side • True pair

17. Rapidly Spinning Tight Loops (Feedback) • Continuous planning • Iterative development • Continuous integration • Test first development

19. Iterative Development • Take your deadlines seriously

20. Subjective Criteria for Success (Simplicity) • How do I know a good metaphor? • What is simple? • How do I know what to refactor? • Is this enough tests, or too many?

21. Simple • Testable • Browsable • Understandable • Explainable

22. Simplicity is a Balance • Simplicity and complexity are the yin and yang of software • As complexity is added to a system you must add simplicity in the right measure to balance.

23. Increasing Simplicity • Good names • Design patterns • Refactoring • Abstractions • Object Oriented Programming • Distributed Objects? Yes, but...

24. What is a good Metaphor? • Story • Memorable • Based on knowledge • Guessable • Code • The actors in the story • A few easy to read objects • Sweep them clean often

25. Knowledge is Compiled Information Information + Your brain (compiler) + Time Knowledge

26. No Fall Back Excuses (Courage) • You don’t have time to cover your ass

27. What Makes it Successful? • Social activities (communication) • Rapidly spinning tight loops (feedback) • Subjective criteria for success (simplicity) • No fall back excuses (courage)

28. Prerequisites for XP • Management support • Customer support • A team willing to try new things without being forced In other words everyone

29. Managers • Look after the people and the project’s resources • Solve process and organization problems • Maintains the precious developer customer relationship • Has a sense of direction and overall scope when the customer does not

30. One Way to Transition to XP • Add one practice at a time • Fix your worst problem first • Encouragement for compliance • No consequences for non-compliance Another Way to Transition to XP • Start out by the book • Change what ever doesn’t work

31. Transitioning • Just because someone realizes what they have is not working does not mean they are ready for change.

32. XP Is Like a Roller Coaster Ride • Click-click-click, as you go up the first hill • Whoosh, you go fast and too soon the ride is over • You slowly roll into the station calm and relaxed after the excitement and ready to go again