XP Explained
Chapters 7-9
Primary Practices

Sit together




Ideal
Resistance
Multi-site
Whole Team



All the necessary skills in a single
management structure
This is dynamic
No fractional staff
Primary Practices

Informative workspace




Key metrics as big graphs and charts
Visible planning and tracking
Requirements groups
Energized Work


40 hour week
Focus time
Primary Practices

Pair Programming
(switch as needed, maybe
multiple times per day)





Keep each other on task
Brainstorm
Clarify
Switch lead when one is stuck
Hold each accountable
Primary Practices

Pair Programming and personal
space


See figure 6 page 44
We like our personal space!
Primary Practices

Stories

Plan using units of customer visible
functionality
Provide a 2 click way for customers to dial
frequently used numbers
 Make technical requirements visible with
test cases



Requirement is a misnomer
Value cannot be determined with out
cost estimates
Primary Practices

Weekly Cycle

Weekly meeting
Review progress
 Customer pick new weeks worth of stories
 Break stories into tasks, team members
sign up for tasks and estimate them


Start the week by writing automated
test
Primary Practices

Quarterly Cycle


Reflect on the team, project, progress.
Process, and alignment with larger goals
Quarterly meeting
 Identify bottlenecks
 Initiate repairs
 Plan themes
 Big picture – where the project fits within
stakeholder concerns
Primary Practices

Slack


Everything can’t be planned
Include tasks in the plan that could be
dropped
Primary Practices

Ten Minute Build


Automatically build and test in 10
minutes.
What if you can’t

You can more often that you think
Primary Practices

Continuous integration



Integrate and test changes after no
more than a couple of hours
Integration can take more time that
the original programming
Synchronous is better than
Asynchronous
Primary Practices

Test first Programming



Write the tests before the code –and do
it at a very fine level of granularity.
If it is hard to write a test you have a
design problem not a test problem
Rhythm
Primary Practices

Incremental Design




Invest in the design of the system
every day
Defer design decisions to the last
responsible moment
The most effective time to design is in
the light of experience
The closer the implementation of a
design mechanism to the time it is
actually needed, the more efficient
Chapter 8
Getting Started
Getting Started

Make adopting XP an XP project

Write stories
Educate management
 Attending training
 Automate the build




Prioritize the stories
Estimate their time and cost
Create and track metrics
Chapter 9
Corollary Practices
Corollary Practices

Real Customer Involvement

Make your stakeholders part of the
team
Corollary Practices

Incremental Deployment

Run parallel systems if necessary
Corollary Practices

Team Continuity

Don’t throw everyone back into the
“labor pool” once a project is finished
Corollary Practices

Shrinking Teams

As a team grows in capability, keep its
workload constant but gradually reduce
its size
Corollary Practices

Root Cause Analysis




When you find a defect, eliminate the
defect and the cause
The goal is that the team won’t ever
make the same mistake again
I expect that individuals will make
mistakes, but my process should
ensure that my team doesn’t make
mistakes
Five whys
Corollary Practices

Shared Code

Anyone can improve any part of the
system at anytime
Eliminates bottlenecks
 Doesn’t work across team boundries

Corollary Practices

Code and Tests

Maintain only the code and tests as
permanent artifacts. Generate other
documents from the code and tests.
Rely on Social mechanisms for the rest.
Corollary Practices

Single Code Base


Duplication is not fun and it is very
expensive
Frameworks can help solve this
Corollary Practices

Daily Deployment

Put new software into production every
night
Corollary Practices

Negotiated Scope Contract

Write contracts that fix time, costs, and
quality but call for an ongoing
negotiation of the scope


Fix scope but leave specific requirement
to ongoing negotiation
Sign a series of shorter contracts rather
than one big one