misc

Have references memorized: Royce (waterfall), Tom DeMarco and Laurie Williams (pairing), Steve McConnel (exponential cost increase)

As in a consultant-client relationship, a good first question is: "If you could improve one aspect of your projects, what would you change?"

When confronted with questions about architecture, respond with: "But imagine if it was possible to develop in this way and have superior architecture, would you want to know more?"  This is also a good opening to begin discussing the practices of this approach, the practices that allow it all to happen.

Say "XP" as infrequently as possible.  Leave "Extreme Programming" in the title, but use words like Approach, Philosophy or Discipline in presentation.


slide 0

* This approach emerged around 1997.  In 2000, the Agile Manfesto was composed.
* The bottom line: What does this approach deliver?  How does it maximize business value? 


slide 1

Defining the four properties of business value


slide 2

Diagram the waterfall.

Waterfall assumes that the later changes occur, the more costly they will be.  Waterfall minimizes costs through spending a lot of time "up front", thoroughly designing the system.

With Waterfall, the sponsor must stick with the original priorities for the entire process or accept a higher cost or delayed release date.


slide 3

This philosophy assumes that it is extraordinarily to difficult to get the system communicated and designed correctly on the first try.  Iterative Development minimizes costs by increasing the frequency and amount of feedback between the system, the development team, and the business sponsor. By ecouraging the sponsor to steer, the current business goals are always the top priority.

Iterative has an excellent side effect: improved estimates.

Repetition is the best way to improve at anything. 

slide 4

Draw the chart.

Steering is the critical point in this presentation.  Maximizing business value is absolutely dependent on the customer steering development.  If the customer isn't steering, the final product will not match up with what the customer actually wants on the release date, regardless of what they said they wanted at the beginning of the project.

The customer prioritizes which features should be implemented first.  This ensures that the system always has the most possible value.

Business value is maximized through not doing what they don't need:  "barely sufficient"

Features
o o o o o
o o o o o  Set of requested features
o o o o o

1 o o o o
o o 1 o o  First iteration
1 1 o o o

1 o o o o
2 o 1 o 2  Second iteration
1 1 2 o 2

1 3 o 3 o
2 o 1 3 2  Final iteration: the "o's" represent business value...unneeded features
1 1 2 3 2


slide 5

So how do we implement the features the customer wants?  This approach pays attention to implementation.  In order to be responsive to change, a set of practices are used to keep the system simple, clean, and flexible.  The practices also increase developer accountability and therefor productivity.


slide 6

whole team: project manager + coach + developers + customer = team;  team shares an open space
customer tests: customer defined acceptance tests developed in parallel with system by the customer
small releases: iterative development
planning game: defining the requirements with the customer and determining feature scope

collective ownership: any developer can change any aspect of the system
continuous integration: the entire system is built continually, multiple times per day
metaphor: system design is based on a shared metaphor
sustainable pace: 40 hour work week
coding standard: development team agrees on standard coding conventions and development environments

test-driven development: test are written first, code is developed to get the tests to pass
pair programming: all development is done in pairs
simple design: do the simplest thing that could possibly work
refactoring: improving code clarity and system design without changing its functionality