DEV Community

loading...
Cover image for DEV3L on Extreme Programming Explained

DEV3L on Extreme Programming Explained

Justin Beall
Software engineer (Python/Node/Java), craftsperson, XP advocate, agile technical coach, product discovery/delivery/management/owner curious, data miner, believer in growth mindset, multiplier, servant
・3 min read

Although Extreme Programming has been around for over twenty years now, the methodologies and concepts explained would be considered radical to many organizations. In Extreme Programming Explained - Embrace Change, Kent Beck explains how a set of aligned values, combined with a human-centric approach to software development, and focus on shortening feedback cycles, dramatically changes the programming landscape.

XP is about social change

Turn the dials to 10 - Extreme

Values:

  • communication
  • simplicity
  • feedback
  • courage
  • respect

Find starting place, get started, and improve from there

No one stumbles into excellence

Principles:

  • humanity
  • economics
  • mutual benefit
  • self-similarity
  • improvement
  • diversity
  • reflection
  • flow
  • opportunity
  • redundancy
  • failure
  • quality
  • baby steps
  • accepted responsibility

Software Development is a game of insight that comes to prepared, rested, and relaxed minds

Practices:

  • sit together
  • energized work
  • pair programming
  • stories
  • weekly cycle
  • quarterly cycle
  • slack
  • ten-minute build
  • continuous-integration
  • test-first programming
  • incremental design

Write all production programs with two people sitting at one machine. Beck's experience: "Pairs are more than twice as effective" - more value

Longer wait to integrate - more costs and more unpredictable

If it's hard to write a test,
it's a signal that you have a design problem,
not a testing problem

Incremental design suggests the most effective time to design is in light of experience

Change begins with awareness

Corollary Practices:

  • real customer involvement
  • incremental deployment
  • team continuity
  • shrinking teams
  • root-cause analysis
  • shared code
  • code and tests
  • single code base
  • daily deployment
  • negotiated scope contract
  • pay-per-use

XP Health Metrics:

  • defect count
  • flow (idea to revenue)

Incentivize team performance over individual performance,
social over cowboys

Theory of Constraints:

Maximize production capacity of the system, need to maximize throughput at bottleneck - avoid the local maximum trap

  • value stream map
  • implement pull system, not push

If bottleneck exists outside of development,
then answer must come from outside

Planning:

Planning XP is an activity, not a phase

Continuous planning to determine how much can get done each iteration

Iron Triangle, only scope negotiable

More time at the desk does not equal increased productivity for creative work

Plan based upon "yesterday's weather",
past iteration done to plan next capacity

Quality

Reduce the occurrence of defects to a level where trust can reasonably grow on the team

Sooner find a defect, cheaper to fix

Continuous design

Test first decouples interface from implementation

When confronted with a ball of mud,
begin lighting lamps where you walk - campsite rule

If you eliminate enough waste, soon you go faster than the people who are just trying to go fast

Community

First change myself,
then offer fruits of that change to others

Expecting others to do what you're not willing to try yourself is disrespectful and ineffective


"If you're looking for a world in which you can be comfortable, living in balance and do good business; XP is a way of thinking about and acting on your ideals."


Reference Journal Events: Start, Finish

Discussion (0)