One XP Experience: Introducing Agile XP Software Development into a Culture that is Willing but not

1
One XP Experience Introducing Agile (XP)
Software Development into a Culture that is
Willing but not Ready

• Joe Bergin
• Fred Grossman
• David Leip
• Sue Merritt
• Olly Gotel

IBM
Pace University
2
Background

• IBM Webmaster maintains a large and complex web
  site
• 2,000,000 pages
• Many applications/Complex architecture/ Dynamic
• Mission Critical
• Development crosses managerial lines

3
Inception

• Experiment at IBM
• Will agile processes work in the Webmasters
  domain?
• David invites Fred Grossman and Joe Bergin to
  explore the question with his organization
• Original thought was to run a pilot project with
  Fred and Joe training and coaching the team

4
Wisdom

• Pick a reasonably sized project for the first
  attempt at any new methodology
• Pick a project that is not mission critical
• Train everyone thoroughly
• Set up required infrastructure
• Learn
• Evaluate

5
Reality

• There was no time to initially train everyone
• The team was not in place
• There was no time to discover, much less set up,
  the infrastructure
• The project ultimately chosen was
• MISSION CRITICAL
• Looming fixed project deployment deadline
• Start or fail

6
Complexities

• Webmaster applications use people with a variety
  of non-interchangeable but critical skills.
• Application development is not localized in a
  single part of the organization, and reporting
  lines go all the way to the top.

7
Advantages

• People are eager
• People are skilled, though with a different skill
  sets
• People are motivated (most positive and a few
  negative)
• People like each other and work well together

8
Training

• Fred and Joe gave most of the participants an
  overview of XP
• An all day exercise (Extreme Construction) was
  used to introduce the practices
• A virtual retrospective of prior projects was
  done to capture the organizations sense of their
  existing methodology

9
Execution

• The team (developers and customer) was formed
• Customers (2) wrote lots of stories
• Team estimated, then built the stories
• Fred and Joe coached the team, daily at first,
  then several times per week.

10
Success

• The customer got usable functionality that would
  not have been delivered with the standard
  methodology by the pre-determined deployment date
  the, BUT
• Would have liked more functionality
• Was often frustrated with the pace and the
  awkwardness of some of the practices

11
How well did we do XP ()

• Planning Game
• Onsite Customer - whole team
• Short Iterations
• Standup Meeting
• Coding Standard

• Retrospectives
• Metaphor
• Sustainable Pace
• Simple Design
• Common Code ownership

12
How well did we do XP (-)

• Pair Programming (collaboration only)
• Constant Refactoring
• Test First Development
• Continuous Integration
• Initial confusion with the distinction between
  iterations and releases

13
Problems

• The coaches were never able to really convince
  the team of the advantage of the practices not
  done, though the team saw the consequences.
• The team was breaking new ground (for themselves
  at least) requiring a very complex testing
  environment that never quite came together.

14
Values

• Courage
• Feedback
• Simplicity (mostly)
• Communication

15
Risks

• The code quality could be better
• Lack of automated test suites makes refactoring
  and maintenance difficult
• Bugs appeared that should not have, frustrating
  everyone and slowing the process down

16
Conclusions

• While the project was technically a success
• The practices not practiced held us back and
• left some risks
• More early training could have solved some of
  this (pairing and TDD)
• Better infrastructure preparation could have
  solved much of the rest (testing infrastructure)

17
Conclusions (2)

• One of the anomalies we had to cope with is that
  while the team did not follow all the practices,
  the methodology appeared to be working, although
  exposing them to some risk.
• In some cases the team followed modified
  practices.
• The full set of practices is necessary when
  building a community with an agile culture.