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 *

* Pace University ** IBM

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

Inception

• Experiment at IBM– Will agile processes work in the Webmaster’s

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

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

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

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.

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

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 organization’s sense of their existing methodology

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.

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

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

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

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.

Values

• Courage

• Feedback

• Simplicity (mostly)

• Communication

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

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)

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.