Extreme Programming (Kent Beck, 1999) is an agile approach characterized by

• pair programming,
• test first
• short development cycles (7-10 days) between releases,
• sustainable pace
• Search for simplest increments with no “big design up front”

1 Values

1 Values

• Communication

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

  • Understanding what has changed & what we are getting wrong

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

  • Understanding what has changed & what we are getting wrong
  • Includes opinions & observations on what turned out to be complicated, hard to do, hard to get right, etc.

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

  • Understanding what has changed & what we are getting wrong
  • Includes opinions & observations on what turned out to be complicated, hard to do, hard to get right, etc.

• Courage

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

  • Understanding what has changed & what we are getting wrong
  • Includes opinions & observations on what turned out to be complicated, hard to do, hard to get right, etc.

• Courage

  • a bias toward action

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

  • Understanding what has changed & what we are getting wrong
  • Includes opinions & observations on what turned out to be complicated, hard to do, hard to get right, etc.

• Courage

  • a bias toward action

• Respect

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

  • Understanding what has changed & what we are getting wrong
  • Includes opinions & observations on what turned out to be complicated, hard to do, hard to get right, etc.

• Courage

  • a bias toward action

• Respect

  • care about the team members

1 Values

• Communication
• Simplicity

  “What is the simplest thing that could possibly work?”

• Feedback

  • Understanding what has changed & what we are getting wrong
  • Includes opinions & observations on what turned out to be complicated, hard to do, hard to get right, etc.

• Courage

  • a bias toward action

• Respect

  • care about the team members

  • care about he project

2 Principles

2 Principles

• Humanity: concern for the team members

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

• Mutual Benefit: “Every activity should benefit all concerned.”

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

• Mutual Benefit: “Every activity should benefit all concerned.”

  • e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

• Mutual Benefit: “Every activity should benefit all concerned.”

  • e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs

  • negative example: extensive internal documentation

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

• Mutual Benefit: “Every activity should benefit all concerned.”

  • e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs

  • negative example: extensive internal documentation

• Self-similarity

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

• Mutual Benefit: “Every activity should benefit all concerned.”

  • e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs

  • negative example: extensive internal documentation

• Self-similarity

  • when you find a pattern (code or work practices) that works, stick with it

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

• Mutual Benefit: “Every activity should benefit all concerned.”

  • e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs

  • negative example: extensive internal documentation

• Self-similarity

  • when you find a pattern (code or work practices) that works, stick with it

• Improvement

  “In software development, ‘perfect’ is a verb, not an adjective.”

2 Principles

• Humanity: concern for the team members

• Economics: Make sure that what you are doing has value to the customer.

• Mutual Benefit: “Every activity should benefit all concerned.”

  • e.g., automated tests help me (the developer) design & code today. Also benefit maintainers down the road. Benefit customers by improving reliability and reducing costs

  • negative example: extensive internal documentation

• Self-similarity

  • when you find a pattern (code or work practices) that works, stick with it

• Improvement

  “In software development, ‘perfect’ is a verb, not an adjective.”

• Diversity: skills attitudes, and perspectives

Principles (cont.)

Principles (cont.)

• Reflection:

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

• Redundancy

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

• Redundancy

  • critical, difficult problems approached many ways

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

• Redundancy

  • critical, difficult problems approached many ways

• Failure

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

• Redundancy

  • critical, difficult problems approached many ways

• Failure

  • should not be feared

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

• Redundancy

  • critical, difficult problems approached many ways

• Failure

  • should not be feared
  • prototypes and experiments are useless if only employed when we are sure they will succeed

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

• Redundancy

  • critical, difficult problems approached many ways

• Failure

  • should not be feared
  • prototypes and experiments are useless if only employed when we are sure they will succeed

• Quality

Principles (cont.)

• Reflection:

  • time is set aside to review how well development is going,
  • informal reflection within team is encouraged

• Flow: continuous flow of activities rather than discrete phases

• Opportunity (rather than problems)

• Redundancy

  • critical, difficult problems approached many ways

• Failure

  • should not be feared
  • prototypes and experiments are useless if only employed when we are sure they will succeed

• Quality

  • Quality is not a control variable. Projects don’t go faster by accepting lower quality."

Principles (cont.)

Principles (cont.)

• Baby Steps

Principles (cont.)

• Baby Steps

  • Organizations can add XP practices incrementally

Principles (cont.)

• Baby Steps

  • Organizations can add XP practices incrementally

• Accepted Responsibility

Principles (cont.)

• Baby Steps

  • Organizations can add XP practices incrementally

• Accepted Responsibility

  • “Responsibility cannot be assigned. It can only be accepted.”

Principles (cont.)

• Baby Steps

  • Organizations can add XP practices incrementally

• Accepted Responsibility

  • “Responsibility cannot be assigned. It can only be accepted.”
    • Whoever signs up to do work also estimates it.

Principles (cont.)

• Baby Steps

  • Organizations can add XP practices incrementally

• Accepted Responsibility

  • “Responsibility cannot be assigned. It can only be accepted.”
    • Whoever signs up to do work also estimates it.
    • The person implementing a story is responsible for design, implementation, and testing.

3 Practices

(Beck, Extreme Programming Explained, Figure 3)

We’ll focus on the primary ones in the upper half of this diagram.

3.1 Teamwork

Whole Team

• Team must span the required skill set for the project

• People need a sense of belonging, of shared purpose

  • Splitting people across projects detracts from these

3.2 Energized Work

3.2 Energized Work

• “Work only as many hours as you can be productive”

3.3 Planning

Stories

• Units of planning.

“the word ‘requirement’ is just plain wrong. Out of one thousand pages of ‘requirements’, if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80%? Not ‘requirements’; they weren’t really mandatory or obligatory.”

• Stories lead to earlier estimation than requirements
  • Encourages team to think in terms of greatest return from smallest investment.

3.4 Integration

Ten-Minute Build

• Automated build should build and run tests in tem minutes

• Anything longer should be done less frequently.

  “A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn’t give you time to drink your coffee.”

3.5 Programming

Test-First Programming

• Write a failing test before changing any code.

  Addresses:

  • scope creep: putting in code “just in case”
  • coupling and cohesion: If it’s hard to write a test, you have a design problem, not a testing problem.
  • Trust: (team building)
  • Rhythm