Q:

Why did you start using XP?

A:

I took the job of bringing thirteen different product teams into one organization with one architecture and one look-and-feel. XP was part of my strategy. I came in and said, “The process is XP!”

Q:

How many people are in your organization?

A:

We have three hundred people in Airline Products Development: 240 developers, twenty-five in management and clerical, and thirty-five in testing and configuration management.

Q:

How did you bring XP in?

A:

Each of the thirteen product groups got a week of training from Object Mentor. Thirteen groups in thirteen weeks. We followed that up with coaching as the teams began using XP.

If I had it to do again; I would start with one team, make sure they really “got” XP, then have them teach the next team.

Q:

Do you use all of XP?

A:

I have a dial in my head. For projects that fit XP, we do everything. The perfect XP project is greenfield development in Java with a motivated team. If we have to extend legacy C++ code, we have to embed XP in a more waterfall-ish project. We do more requirements and design work up front. And, we have a formal testing phase before we deploy to our customers.

The legacy projects can't keep the design simple because the design isn't simple to begin with. Because of the design complexity they can't write enough tests, and so there are too many bugs. Also, they have a hard time refactoring because of the lack of refactoring tools in C++. That's what leads to the waterfall phases at the beginning and end of the projects.

Q:

What benefits have you seen from XP?

A:

The pure XP projects have very few defects. We have one project that hasn't had a single defect in the two years it's been in use. The legacy XP projects have very competitive defect rates, one to two defects per thousand lines of code. The Bangalore SPIN, consisting of ten CMM level-five organizations, reports an average of eight defects per thousand lines of code. Productivity is also up, 40% on one project where we can compare XP and pre-XP development directly.

Q:

XP can't have been easy for you.

A:

No. At first, a third of the people are skeptical, a third buy in quickly, and a third wait and see. Eventually, 80–90% buy in, 10–20% use XP grudgingly, and 3–5% never buy in. If programmers won't pair or if they insist on owning code, have the courage to fire them. The rest of the team will bail you out.

Q:

Tell me about your on-site customers.

A:

A lot rides on the customer. Our customers come from our product management organization. Each team has a customer who sits in the same open space with the rest of the team. One product might have one hundred airlines as customers, so it's the product manager's job to represent all of the airlines' interests. The product managers gather requirements at users conferences, customer forums, and design councils. The design councils are most valuable. Once a year, we invite a few of the best customers for a product to come in and tell us what they want to see next. We get a year or two worth of stories at one of these design councils. We have senior developers sit in on these meetings, but it's the product manager who has final say on features.

The use of on-site customers is one of the most valuable parts of XP, but it also causes the most problems. It's great to be able to manage scope. It's great to be able to know a quarter of the way through a schedule whether you are going to make it. Without careful watching, though, scope management can turn into scope creep.

Some of our customers are great. They write good stories. They write acceptance test criteria. They help testers write acceptance tests. Some of the customers aren't so good. They want to write high-level stories, but they aren't interested in writing acceptance test criteria. In those cases, we have some very experienced developers who know a lot about the domain fill in. We've had a couple of cases where customers have tried to game the system by concealing requirements to keep the estimates down, then expecting to get the whole feature they imagine when the time comes.

Q:

What advice do you have for other executives who are considering XP?

A:

Definitely use XP. Plan by features. The items in the plan should be features that customers care about. Plan releases once a quarter. Plan iterations more frequently. We have two-week iterations. Make the iterations absolutely fixed. Have the customers sit with the team. Put the team in an open space. If you have to embed XP in waterfall-style development, you'll still get plenty of benefit.