Extreme Programming (XP) - Core values explained

Extreme Programming is a light-weight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements. Developed by Kent Beck (earlier helped create Class-responsibility-collaboration card, a viable alternative to UML sequence diagram to design the dynamics of object interaction and collaboration.) which is an Alternative to “heavy-weight” software development models  (which tend to avoid change and customers). Here is how IEEE view Extreme Programming.


"Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the
far-flung future, XP programmers do all of these activities a little
at a time throughout development.”
-- IEEE Computer , October 1999

Success in industry
Chrysler Comprehensive Compensation system
   –After finding significant, initial development problems, Beck and                   Jeffries restarted this development using XP principles
   –The payroll system pays some 10,000 monthly-paid employees         and has 2,000 classes and 30,000 methods, went into production almost on schedule, and is still operational today
Ford Motor Company VCAPS system
   –Spent four unsuccessful years trying to build the Vehicle Cost and Profit System using traditional waterfall methodology
   –XP developers successfully implemented that system in less than a year using Extreme Programming.

Scrum vs XP – What is the difference?

1. Scrum is more high level, focusing on the management of the project (e.g. the requirements or features are managed) rather than specifying or defining engineering practice such as pair programming or test driven development
   
2. The length of an iteration in XP is usually 1-3 weeks whereas, in Scrum sprints are 1-4 weeks
   
3. Once sprint (or iteration in XP) starts, customer cannot change the requirements, in other words the customer will have to wait until the sprint (or iteration in XP) finishes. In XP however, requirements can change anytime
   
4. In XP features are developed in a strict order whereas in Scrum, the team is free to choose the features to be developed. Sequence does not matter
   
5. Both XP and Scrum define the role of a coach, In Scrum it is called Scrum Master and requires (or strongly recommended) certification, whereas, XP defines the role of coach quite informally and the role may float between members of the team.
   

  Scrum and XP are often used together: Scrum defines the framework and XP defines the engineering practices and they fit together nicely.

Embrace change
  In traditional software life cycle models, the cost of changing a program rises exponentially over time. Why would it cost more to make large changes during testing than during requirements specification? A key assumption of XP is that the cost of changing a program can be hold mostly constant over time. Hence XP is a lightweight (agile) process. 

• Instead of lots of documentation nailing down what customer wants up front, XP emphasizes plenty of feedback. 
  
• Embrace change: iterate often, design and redesign, code and test frequently, keep the customer involved
  

• Deliver software to the customer in short (2-3 weeks) iterations
  
• Eliminate defects early, thus reducing costs
  

Above pictures are self descriptive, anyway please check my other posting "Extreme Programming practices explained" for more detailed explanation.

Core Values
Communication
Think about it, What does lack of communication do to projects?

XP emphasizes value of communication in many of its  practices:
–On-site customer, user stories, pair programming, collective ownership (popular with open source developers), daily standup meetings, etc. XP employs a coach whose job is noticing when people aren’t communicating and reintroduce them


Simplicity
''Do the simplest thing that could possibly work'' (DTSTTCPW) principle. Elsewhere known as KISS (“Keep It Simple, Stupid!”). A coach may say DTSTTCPW when he sees an XP developer doing something needlessly complicated. Follow YAGNI principle (''You ain’t gonna need it''), keep it to the point of interest. simplicity and communication support each other,

Feedback


Feedback is an essential tool for successful project deliveries. Feedback should be invited at different time scales. Unit tests tell programmers status of the system. When customers write new user stories, programmers estimate time required to deliver changes. Programmers produce new releases every 2-3 weeks for customers to review. Valuing feedback turn the waterfall model upside down.

Courage

XP teams (expected to) have the courage to communicate and accept feedback. They have the courage to throw code away (prototypes), and re-factor the architecture of a system. Design, architecture or prototype changes are no longer a worry for Software development process, do you see the change?

Respect

Without which you can never be successful, is our last value, Respect. Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects the team’s right to accept responsibility and receive authority over their work.