Extreme Programming and Agile Processes

David Laurance / Dennis Mancl

Princeton ACM/IEEE-CS talk
December 19, 2002

Outline

How do we organize the job of software development?
Introduction to XP
Planning an XP project
Pair Programming
Agile Processes – when you can’t use XP

Chaotic software development process

Development process #1: start writing a program, ship it when it is finished

works kind-of OK for a small problem and a single developer
it’s mostly what you did as a student
managing the process is pure guesswork
can’t use this process for big software problems

Waterfall software development process

Development process #2: create a team, follow a well-documented process with fixed milestones

managing the project is easier
lots of time “wasted” writing documentation
need good understanding of the requirements
testing often gets short-changed
sometimes turns into a “death march”

Typical “waterfall” development process

1) collect and document all of the system requirements
2) produce a set of design documents
3) write code that implements the pieces specified in the design
4) integrate all of the pieces and test to make sure the system satisfies the requirements
5) package the system and ship to the customer

Iterative software development process

Development process #3: analyze a little, design a little, code a little (Boehm “spiral process”)

more difficult to manage, hard to know when you are “done”
you get to deliver early versions of the most important features, get customer feedback quickly
you can get by with less documentation
it is easier to react to customer changes

Methodology

Methodology: the set of ground rules that a software development team uses to organize their work:

a heavyweight methodology has many rules, practices, and documents
a lightweight methodology still has some rules, but they are chosen to be easy to follow

Extreme Programming

Extreme Programming (XP) is a lightweight process
Ground rules:

small team (2 to 12)
continuous access to customers
OO design and code (Smalltalk, Java)
change management system (code and tests)
the system is always “working” (growing functionality over time)
overall development cycle – between 4 and 12 months
new release to customer every 2-3 months
internal iterations every two weeks
not for life-critical systems (heart monitor, nuclear power plant, avionics systems, etc.)

Some Rules of Extreme Programming

Planning rules

do project planning via “user stories”
plan a series of very small internal releases
start each day with a “stand-up meeting”

Design rules

keep the design simple (use the simplest thing that could work)
refactor as needed

Coding rules

talk with the customer throughout the coding process
always code in pairs
code unit tests first
follow coding standards

Testing rules

unit tests for all code
acceptance tests for each user story

Information on XP

Books:

Extreme Programming Explained (Kent Beck)
Planning Extreme Programming (Beck and Fowler)
Questioning Extreme Programming (McBreen)

Web sites:

A day in the life of an XP developer

First thing in the morning: developer attends a stand-up meeting with the rest of the team (10-15 min)

developer chooses a task (part of a user story); chooses a development partner for the day

Developer and partner sit together and do the development work for the task

write new unit tests, check them into the change management system
write new code, check it in
fix things that need to be changed in existing code; rerun the unit tests
run the new unit tests; run the acceptance tests for the user story

Developer goes home at 5:00 (no overtime)

Planning an XP project

User Stories

Capture requirements “in the users’ words”
Small, discrete, testable
Include scenarios
May include business interactions outside system

“Planning Game”

Users own stories
Developers set and own estimates
Users set priorities – “business value”
Joint goal: group stories into iterations
Business value
“Worst first”

Planning an XP project

Interview the customer; write user stories on index cards
Developers give development estimates for each story

estimates in “ideal person-days”
estimates based on experience with similar problems

If a story is too big, split it into smaller stories
Create a release plan – list the stories in each release

highest priority or “risky” items early

Track execution of the plan

Post the user stories on a bulletin board (in time order)
Check off each user story after the code is complete and the acceptance tests have passed

Examples of User Stories

see http://www.c2.com/cgi/wiki?UserStoryExamples

Pair Programming

One important practice in XP: all code is reviewed as it is written

how does pair programming work?

two developers, one workstation
one person is the driver, the other is the navigator
the navigator suggests design alternatives, checks for conformance to coding standards, prevents driver from writing unreadable code
pair assignments usually change every day

reduces the need for elaborate design documentation
pair programming actually improves productivity

Pair Programming Experiences

“It’s sometimes harder work, because my partner makes me justify everything that’s unclear or disagreeable.”
“It doesn’t seem to me that we’re productive at the time…but when we get done, we find that we’ve written a great deal of code that we understand and like.”
“I've had the pleasure to experience such a successful partnership when my co-programmer and I have been on the same wavelength… However, I've also experienced the other end of the spectrum where my co-programmer has been a silent partner.”

Pair Programming Problems

Some people would rather work alone

“cowboy programmers” – you don’t want them on your team

Novice programmers slow down experts

novices will learn to enough to be able to modify and extend the expert’s code later

“It’s too expensive”

pair programming avoids a lot of debugging and rewriting costs

XP Challenge:

How can you align individual interests?

Within the project?

Users, Developers, Coaches
Individual vs. Team success

Across the organization?

How will success be recognized?
What is rewarded in the corporate culture at large?

Is XP for everyone?

XP has four important values:

communication – XP can’t work if developers are unwilling to talk with each other, or if the development team can’t talk with the customer
simplicity – in order to minimize the cost of constantly modifying the code base, the developers must resist overdesigning, and they must refactor the designs often
testing – the pace of development requires that complete automated testing be used by the whole team
courage – developers must have the courage to make forward progress at all times

Industry experience says:

need management buy-in and support from the customer
a “coach” for the team is a really good idea

Agile Processes

“Agile” is a generalization of XP
Examples of agile processes:

Crystal Clear
Scrum
Adaptive Software Development
DSDM [Dynamic Systems Development Model]
Lean Development

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Alliance: http://www.agilealliance.org

Agile principles

Agile software development follows a small number of basic principles:

customer needs come first – so keep listening for changes in requirements, don't reject new requirements just because “the requirements are already signed off”
deliver software (and other artifacts) often – don’t wait for months to get feedback
in the development world, people are more valuable than computer tools – and face-to-face communication is the most efficient way to convey
complex information (both with other developers and with customers)
working software is the primary measure of progress

Agile characteristics

Most of the agile processes are “controlled chaos”:

short development iterations, with product “shipped” to either a customer or a pseudo-customer at regular intervals
continuous testing – such as daily regression tests
collecting customer requirements using scenarios or use cases
small team sizes
informal modeling techniques – CRC cards, simple drawings on whiteboards
adaptive planning techniques – plans are updated based on intermediate results and reprioritization by the customers

Agile versus XP

Most agile process are less radical than XP:

don’t require pair programming
multiple roles, not just “general-purpose developer”
various methods of iteration planning
existing heavyweight processes can be adapted to be more “agile”

Which agile process?

Scrum

Scrum is a very general iteration management process, which can be used in conjunction with any methodology
development activities are in 30-day “sprints”

Adapt existing processes

OOPSLA experience report on “agile” version of Rational Unified Process
oopsla.acm.org/extra/pracreports/MakingRUPAgile-Report.pdf

Crystal Clear

much lighter than XP, but the team must define their own “required project documentation”
see Agile Modeling by Scott Ambler for ideas
good for a team of 4 to 6 people

Books on Agile Processes

Crystal Clear: Writing Effective Use Cases (Cockburn)
Scrum: Agile Software Development With Scrum (Schwaber and Beedle)
Adaptive Software Development: Adaptive Software Development (Highsmith)
DSDM: DSDM, Dynamic Systems Development Method: The Method in Practice (Stapleton)
Lean Development: Lean Development: A Toolkit for Software Development Managers (Poppendieck)

full text at http://www.poppendieck.com/ld.htm

Web sites on Agile Processes

Summary

XP: a radical software methodology for small teams

planning by user stories
pair programming
continuous integration; unit tests for everything
developer centered processes
minimal design documentation
need an “on-site customer”

Agile processes

Agile is not as radical as Extreme
still a lot of emphasis on iteration and communication