1

Extreme Programming:From Theory to Practice

Brett PetersonChief Architect & VP of

DevelopmentVisionShare 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 I’d 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

Time

Cost XP

Traditional

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 Practices1. The Planning Game2. On-site customer3. Small Releases4. Testing5. Pair Programming6. Simple Design

11

XP Theory: Twelve Practices7. Refactoring8. Continuous Integration9. Metaphor10. Collective Ownership11. 40 hour week12. 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 Couldn’t justify hardware purchase Was later considered a good decision

15

XP Practice: Initial Decisions Debate: Lab hours

We had developers in from 6:00am to 3:00pm, and others in from 9:00am to 6:00pm

Decided on core lab hours of 9:00am to 3:00pm

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-ment’s 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 don’t 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

Don’t go overboard You don’t 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?