Extreme Programming: Collaboration for Maximum Impact in Minimum Time

Copyright 2002 by Dale Mills and Michele Eicher. This work is the intellectual property of the authors. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the authors. To disseminate otherwise or to republish requires written permission by the authors.

Extreme Programming:

Collaboration for Maximum Impact in Minimum Time

Known Collaborators!

• CollegeNET, Inc.

• Cal Poly San Luis Obispo

• College of Lake County

• University of Richmond

• Dartmouth College

• Emory University

Our Primary Reference

Kent Beck, Extreme Programming Explained: Embrace Change,

Addison-Wesley, 2000; ISBN 201-61641-6

We highly recommend this book as a thought-provoking and fun read.

At present, www.amazon.com lists 18 other books on this subject, and a search of the web returns well over a half-million hits!

“Extreme”??? Well, OK, maybe.

• Positive (and true) connotations• “edginess”/youthful vigor• nontraditional• speed• “traveling light”/mobility• requiring courage

• Negative (and false) connotations• elements of high risk/danger• excessiveness• special or advanced skills required

So, what is Extreme Programming (“XP”)?

• “XP is a lightweight, efficient, low-risk, flexible, predictable, scientific and fun way to develop software” – Beck, p. xvii.

It is extremely dissimilar to other, more cumbersome, time-consuming, structured and safe methodologies, and it leaves behind the practices that waste time, energy and paper (i.e., money) in huge, detailed specification documents, timelines, and hopes of getting it “right” the first time.

What is XP? (continued)

• A coherent set of time-tested, proven techniques which complement and support each other to the greatest possible degree.

• A streamlined method for delivering the right solution quickly and cost-effectively.

Where is XP best used?

• By small teams (2-10 developers)• Within a culture which doesn’t require “big specs”• Within a 40-hr/week programming work environment• When you don’t have to integrate what you’re doing

into existing non-XP applications• Where reasonably fast feedback is available, and

reasonably fast testing is possible• Where the physical layout of workspace permits

close collaboration between programmers (and visiting customers)

• Where you aren’t already in deep trouble on a project and searching for a miracle cure

The Four Control Variables

Cost

ScopeQuality

Time

Who Calls the Shots?

• Business people• Priority of requested functionality• Scope and composition of releases• Dates of releases

• Technical people• Estimates• Advice regarding consequences of options• Definition and control of development process• Detailed scheduling

Traditional “Big Bang” Project

• Extensive requirements analysis• Business specification/requirements doc• Design document and coding specification• “Lather, rinse, repeat” (consecutively)

• Program coding• Unit testing• System testing• Beta/customer acceptance testing

• Eventual production release

Why Traditional Methods Avoid Change

The Exponential Cost Curve

Time

Cos

t of C

hang

e

How would you act if the curve were (relatively) flat?

• You’d make big decisions as late as possible in the process, to defer costs and to wait until more is known so that you’re likelier to be “right”.

• At any given point, you’d only implement what you have to.

• You’d introduce new elements into the design only if they simplified the current code or made future development simpler.

(paraphrased from Beck, p. 24)

Keeping Your “Options” Open

• Option to abandon (salvaging whatever you can)

• Option to switch (changing courses mid-stream)

• Option to defer (postponing critical decisions until the facts are in)

• Option to grow (gracefully scaling up quickly)

The Central Values of XP

• Communication

• Simplicity

• Feedback

• Courage

• Responsibility

• R-E-S-P-E-C-T

XP Development Practices, Part 1• The Planning Game – quickly determine the scope of

a given release by combining business priorities and task estimates

• Small releases – put a simple system into production quickly; release new and improved versions on a short cycle

• Metaphor – create a simple, shared story which describes how the whole system works, so that all involved share “the vision thing”

• Simple (but not stupid!) design. (Probably has a modular structure to limit scope of changes).

XP Development Practices, Part 2

• Testing – including heavy involvement by the customer during each cycle iteration. Automate the suite of tests so that they can be repeated frequently.

• Refactoring – embrace any opportunity to make changes to the system which leave its behavior unchanged but which enhance some non-functional quality (ease of use, flexibility, speed, simplicity of coding)

• On-site customer – keep the customer(s) actively involved in the process at all times

XP Development Practices, Part 3

• Pair programming – Two programmers sit together at one desk, discuss the problem while coding, approaching the task from two very different perspectives

• Collective ownership – anyone can change any of the code at any time, and MUST do so if they see a way to improve it

• Coding standards – voluntarily-adopted rules and conventions emphasize communication through the code and help to minimize conflict/stress/confusion.

XP Development Practices, Part 4

• Continuous integration – roll new code into the release-in-progress many times per day, as soon as a task is complete, running a full suite of tests each so that new bugs or integration problems are detected ASAP.

• 40-hour week – no more than 40 hours of work expected per week, as a rule. No O.T. required a second week in a row.

Management of an XP Project

• Metrics – “Big Visible Chart” as progress indicator, motivator

• Coaching – responsibility for the process as a whole; overseeing its technical execution and evolution while fostering communication, mentoring

• Tracking – gathering and publishing metrics; being the “conscience of the team”

• Intervention – hauling the process back on track where necessary, dealing with turnover, personnel conflicts, etc.

• Light touch – small adjustments here, too

XP in Real Life

• The Players• Track Coach – keeps the system on track• Programmers• Customers – people who actually use the

system• Testers – Combo of Programmers,

Customers & Quality Control• Big “Little” Boss – Pushing the economics

of the process

Our Planning Game• October 2000

• Customer Group Developed• First meeting On-site• XP introduced• Wish list items from all users introduced• General functionality changes introduced• First projected release date July 1, 2001

• October – January 2001• Email Communication• Customer Group Web Site

• Updates of Internal Releases• Screen Shots

Game Plan Continued

• January through April 2001• Internal releases every 2 weeks• On-Site meetings for feedback & testing• April meeting release date pushed back by

customers to October, 2001

• July 2001• More on-site testing with actual databases

• July through October 2001• WebEx Sessions to discuss releases• BlackBoard Courses setup to facilitate discussion

• October 2001• Begin Beta Testing • Testing to end by Thanksgiving

• Release Dates• Revised Release Based on Beta Testing -

End of Year 2001• First Production Release March 29, 2002• Future Point Releases will expand

functionality beyond original scope

Technical Tools Used

• Story Cards• Submitted throughout process

• Email Communication• Conference Calls• WebEx Sessions• BlackBoard Sites• Testing Databases• Feedback Forms

Human Factors – The Bonding

• Food• Play time• Socialization Off-Hours• Relationships Formed• Family Atmosphere• On-site Brainstorming Sessions

• Lots of whiteboards and erasers

• Customers being away from home!!

Benefits

• Customer Group• Broader understanding of

scheduling processes through interaction with different institutions

• Deeper appreciation of CollegeNet’s dedication to customers

• Understanding of the software development process

• CollegeNet• Better understanding of

campus politics and policies

• Better understanding of scheduling practices

• A more user friendly, flexible, and simple yet more complete product

• Regional advocates and auxiliary support resources

Next Time Around

• Even More On-Site Sessions• Longer On-Site Sessions earlier• Longer Beta Testing Period• Customer Observe actual programming• Even More Playing Time • Different Configuration of Room for Customer

Group Meetings• Address Documentation & Training

Final Analysis

• Process was rewarding both personally and professionally for customers and programmers

• A product that we, as customers were eager to use and recommend

• Proud to have our names associated with