Extreme Programming: From Theory to Practice

1
Extreme ProgrammingFrom Theory to Practice

• Brett Peterson
• Chief Architect VP of Development
• VisionShare Inc.

2
XP Theory

• Kent Beck Extreme Programming Explained,
  Embrace Change
• Succinct, practical book
• I read it in 2001.
• Resonated with me based on software development
  process issues Id noticed since 1992
• This discussion based on the 1st edition

3
XP Theory Overview

• Take proven practices and turn them up to 10
• Practice them all the time, down to the
  minute-by-minute level
• Hence the name "Extreme"
• Arguably more disciplined than traditional
  approaches
• Exact opposite of the "cowboy approach"

4
XP Theory Cost of Change Curve
5
XP Theory Cost of Change Curve

• Want to be able to make large changes late in
  product life cycle
• Only implement what is needed
• Increase chances of getting it right
• Flatten the cost of change curve through
  technology and practices
• Simple design without unnecessary extras
• Automated tests
• Practice of constant refactoring

6
XP Theory Four Values

• Value 1 Communication
• Bad communication is the primary cause of
  incorrect software
• Customer to Dev Team and Dev Team to Customer
• Metrics help customer determine progress
• Within Dev Team

7
XP Theory Four Values

• Value 2 Simplicity
• Always create the simplest solution that could
  possibly work
• Be confident that one can successfully implement
  tomorrow's needs

8
XP Theory Four Values

• Value 3 Feedback
• Customer to Dev Team
• Current state of the system (tests)
• Value 4 Courage
• Fixing systemic flaws
• Adding invasive features with confidence
• Plus the Foundation Respect
• Team dynamics are critical

9
XP Theory Twelve Practices

• Turn them all up to 10 and do them constantly
• Done together they
• Flatten the cost of change curve
• Increase quality
• Increase concrete output (working software)
• Increase speed of results by only doing the
  simplest piece necessary
• Increase resource efficiency by only doing what
  is necessary and getting immediate feedback on
  what is correct and incorrect

10
XP Theory Twelve Practices

• The Planning Game
• On-site customer
• Small Releases
• Testing
• Pair Programming
• Simple Design

11
XP Theory Twelve Practices

• Refactoring
• Continuous Integration
• Metaphor
• Collective Ownership
• 40 hour week
• Coding standards

12
XP Practice The Beginning

• 2002 Core group of 5 developers committed to
  trying XP in full
• Found a room amenable as an XP lab
• Kept cubicles
• Effectively unused phone only
• Educated upper management on XP
• Obtained XP lab funding for tables, monitors,
  keyboards, mice, docking stations

13
XP Practice The Beginning

• Moved to a new company (VisionShare) in late
  2004.
• Instituted XP there as well
• Will intermingle both experiences throughout this
  discussion
• Very different experiences and resulting
  decisions

14
XP Practice Initial Decisions

• Debate PCs or laptops?
• Had been using laptops
• XP Theory seemed to imply PCs configured with
  identical development environments
• Stuck with laptops
• Couldnt justify hardware purchase
• Was later considered a good decision

15
XP Practice Initial Decisions

• Debate Lab hours
• We had developers in from 600am to 300pm, and
  others in from 900am to 600pm
• Decided on core lab hours of 900am to 300pm
• Did not want to sacrifice respect for the
  individual at the alter of XP theory
• Enough overlap existed to make it work

16
XP Practice Initial Decisions

• Debate Work Tracking Mechanics
• Notecards or whiteboard?
• I saw almost no value in notecards, but others on
  the team disagreed
• I could not fathom planning via paper
• Tool?
• No good XP tools on the market at that time.
• Found a few open-source, extensible issue
  tracking systems

17
XP Practice Initial Decisions

• Debate Work Tracking Mechanics
• Decided to significantly extend an open source
  PHP-based web issue tracking system called mantis
• Designed out the minimal attributes and views to
  get started
• Implemented as a side project with continuous
  improvements over time
• Still in active use today, 6 years later

18
XP Practice Mantis Extensions

• Categorization of mantis issues into one of three
  hierarchically organized types
• Requirement (Defined the what)
• Story (Refined the what and added some how)
• Task (unit of work for a developer)
• Requirements contained stories which contained
  tasks
• Removed tasks in early 2006

19
XP Practice Mantis Extensions

• Fields for time tracking on tasks
• Rolled up through report views into stories
• Developers tracked Ideal Engineering Hours
  (IEH)
• Actual design and coding (not email or meetings)
• Developers daily updated all tasks with updated
  IEH numbers
• Each developer required to produce six IEH per
  day on average

20
XP Practice Mantis Extensions

• Iteration Views
• An iteration is a time period between planning
  meetings
• We settled on 4 week iterations
• An iteration view showed all work planned for (or
  completed in) an iteration

21
XP Practice Mantis Extensions

• Daily progress percentages
• All views showed the complete of specific
  stories, tasks, or groupings of them (e.g.,
  complete of an iteration)
• Allowed team leader to track and react to
  unexpected IEH expenditure on a daily basis if
  needed
• Critical that developers accurately represent
  IEHs used and remaining IEH usage expected

22
XP Practice Mantis Extensions

• Easy movement of stories and tasks from one
  iteration to another
• Critical for a smooth planning meeting (discussed
  later)
• Screenshots on following pages

23
Main XP Page
24
Stories by Require-ment for an iteration
25
A Require-ment broken into stories
26
Iteration Progress Metrics at Bottom
27
Example Mantis Require-ment Utilizing Attach-ments
28
Example Mantis Require-ments Relation-ships and
Bug Notes
29
XP Practice Planning Process

• Spreadsheet calculates target IEH for a team for
  an iteration
• Considers vacations, sick, and 6 IEH quota
• Estimation Meeting
• Held on Thursday of the last week of an iteration
• Dev team creates group estimates for all stories
  and continues stories that may need more time
  into the next iteration

30
XP Practice Planning Process

• Planning Meeting
• Run by product manager
• All stakeholders have a seat
• Plan the work for the upcoming iteration (based
  on estimates and a target IEH goal)
• Mantis move item functionality is useful
• Review Meeting (eliminated)
• Demonstrate results of previous iteration to all
  stakeholders

31
XP Practice Issues

• Customer Representative role
• Not well filled
• Universally a bad thing to leave unfilled
• Leads to high levels of inefficiency in
  development and frustration with customers/sales
• Filled now at VisionShare with very competent
  product management

32
XP Practice Issues

• Design Documentation
• How much to produce?
• Keep it up to date?
• Is the code the ultimate expression of the
  design?
• Best way to educate new developers?
• We decided in both companies to mostly use design
  documentation in a transient capacity

33
XP Practice Introducing XP

• Buy-in was very high at first company where the
  initiative started.
• Everyone willing to live through rough spots
• Buy-in from second company where process was
  transplanted was mixed.
• Additional developers from first company joined
  the second company

34
XP Practice Introducing XP

• Issues at new company
• Pair programming
• Common tables/workstations
• Daily standup meetings
• Test-first coding
• Big brother time tracking
• Planning process and mantis brought immediate
  results

35
XP Practice Introducing XP

• Compromises made at new company
• Never enforced pair programming
• Did enforce common tables/workstations
• Introduced continuous integration and unit
  testing
• Partially successful at test-first coding
• Used time reporting for roll up and planning
  reasons only

36
XP Practice Lessons Learned

• Every developer needs to be committed to every XP
  principle that is practiced
• Compromise can potentially be used if the
  situation requires it, but it significantly
  reduces the benefit of full XP
• One uncooperative person can cause significant
  disruption
• Respect for the individual must be balanced
  against team needs

37
XP Practice Lessons Learned

• The XP on-site customer role is critically
  important
• Immediate feedback on questions
• Accurate requirements
• Planning process works more smoothly
• Open lab environment is distracting to some and
  liberating to others
• Did significantly increase communication

38
XP Practice Lessons Learned

• Pair programming lessons
• Is exhausting when done correctly
• 6 to 8 hours maximum per day
• Normal mental breaks dont occur
• Can poison a team if personalities clash
• Difficult to hire confidently when pair
  programming is a requirement

39
XP Practice Lessons Learned

• Discipline and conformance
• XP demands conformance
• Core hours, lab environment, etc
• Viewed by some personalities as heavy handed,
  especially time tracking
• Lack of discipline in time tracking causes
  significant difficulties in planning
• Dont go overboard
• You dont want robots

40
XP Practice Lessons Learned

• My top observations after 6 years and two XP
  environments
• The on-site customer is the most important
  practice
• Building an XP process requires complete
  commitment from all developers mgmt
• Individual resistance is magnified due to the
  interactive nature of the process
• Start organically with a committed group

41
Thank you!

• Questions?