Transitioning to XP or The Fanciful Opinions of Don Wells

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

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?

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

Iterative Development Take your deadlines seriously

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?

Simple Testable Browsable Understandable Explainable

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.

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

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

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

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

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

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

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

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

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

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