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”

Kent Beck, 1999

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

• 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

• 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."
• 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)

Primary Practices

3.1 Teamwork

Sit Together

• Open space big enough for whole team
  • small spaces nearby for privacy

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

Informative Workspace

• “An interested observer should be able to walk into the team space and get an idea of how the project is going in fifteen seconds.”

  • Story & task boards
  • “big, visible charts”

Energized Work

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

• “and only as many hours as you can sustain”

Pair Programming

• Write all production programs with two people sitting at one machine.

  Pairs…

  • keep each other on task
  • clarify ideas
  • avoid frustrating “stuck” points
  • keep each other accountable for team quality standards

• Thinking an be done alone, but not coding

• Rotate pairs frequently
  • e.g., every hour or so
  • Eventually, each invidiual should pair with everyone on the team

3.2 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.

Weekly cycle

• Opening meeting
  • Review progress so far
  • Have customers pick a week’s worth of stories
  • Break stories into tasks.

• Start week by writing automated tests for the stories

• Rest of week is implementation and debugging

• At end of week, software is deployable with new functionality

Quarterly Cycle

• At the start of a quarter, reflection and planning

• Reflection

• Planning
  • identify bottlenecks, especially external
    • devise a reaction or workaround
  • Pick the “themes” for the quarter
    • Pick a quarter’s worth of stories to meet that theme
    • Include some slack: minor stories that can be dropped if you fall behind

3.3 Integration

Ten-Minute Build

• Automated build should be 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.”

Continuous Integration

• Integrate and test changes every couple of hours

  “Team programming isn’t a divide and conquer problem. It’s a divide, conquer, and integrate problem”

  • Asynchronous (sometime after checking of changes)
  • Synchronous (on demand by team)
    • provides an opportunity for reflection

• Integration should produce the complete product

3.4 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

Incremental Design

• Create conditions where changes in design do not have exaggerated costs (a la Boehm)

• Adapt the design to changes in (or discovery of) requirements