One of the biggest challenges facing software development teams today is making sure that the end product actually meets the business need. How many times have you seen the cost of making changes—after the original business requirements document is signed off—come between your customer and your development project team? I’ve certainly been a part of teams that struggled to complete projects on original, aggressive timelines while incorporating multiple changes along the way. And even with those changes, the end product turned out to be something other than what the customer expected.

Wouldn’t it be nice to find a development process that embraces the customer’s changes along the way as a natural part of the process? Extreme Programming (XP), created by Kent Beck, is a set of processes designed to do just that. One New York City development firm has embraced these processes and found them effective in managing changes and boosting customer satisfaction. Let’s take a look at the characteristics of XP and see how it has benefited this organization.

Two heads are better than one
Among its tenets, XP requires heavy participation from the customer to define the features, to test and accept the frequent small releases, and to discuss issues that arise while a programming pair codes. (Code is created by two developers: one who codes, the other who focuses on the concepts, provides input, and keeps the pair on track.)

Bill Bumgarner, CTO and partner at CodeFab, a New York City e-applications development company, uses XP as his company’s solution. Over the past 18 months, CodeFab has switched from using a monolithic process for development projects to using XP for all of its development efforts. According to Bumgarner, one of the benefits of XP is that pair programming facilitates communications with the customer. When you need to clarify a question that arises during coding, two developers are better than one.

“When one programmer has that conversation [with the client], you have only one mind to hold the answer. With two people, they’ve been negotiating with each other over how to express the question in the first place, and they’ve been negotiating with each other over how to interpret the answer. The end result is that you have these two people who know the problem very well and know the answer very well. You just don’t get that with one person.”

Change as a constant
XP also involves the client in decision making throughout the project.

“The process is designed to encourage the client to change the specifications as the project is executed. That sounds very scary because as you change things over time, there is a huge cost of change,” Bumgarner said.

However, because both sides are aware that the change may be expensive, they can either decide a change is worthwhile despite the cost or forgo a change because it’s cost prohibitive. The client involvement ensures that each change is carefully evaluated.

“Both the client and the developer team [are] on the same side of the equation. They’re both focused on the problem, whereas before, you always had this contract in the way, so you had the client looking for more work from the developer while paying less money and the developer looking to do less work and get paid more money.”

Who owns the features?
After CodeFab switched to XP, its developers discovered another advantage: Accountability for the feature set is shared by the client.

“In more traditional software development processes, the developers end up being accountable for the feature set of the product, which is not how it should be. If you’re a car dealership and you go out to get an accounting system, you don’t want the people who build the accounting system to define the financial model for your car dealership.”

Although XP makes the client take ownership for the features that are implemented and for setting priorities and pushing for various changes, Bumgarner said this is achieved through collaboration with the developers.

“Once again, it’s both sides working as a team against the problem.”

Change and the contract
Because the wrong kind of contract can shatter a project, XP contracts are written to allow for midcourse corrections. Kent Beck, in his book Extreme Programming Explained, describes the technique of billing time and materials in a bill by hour + day format. He also advises using completion bonuses and late penalties rather than using fixed price/date scope contracts.

At the beginning of every iteration, the customer has the opportunity to change direction by introducing new “stories.” Stories are the use cases, typically written on 3-by-5 cards, at the beginning of the project. The focus on user stories, combined with writing test cases at the beginning, adding frequent releases, and following through on user acceptance testing, can go a long way in helping developers realize those completion bonuses.

“Incremental delivery builds in the opportunity for the customer to terminate the contract if progress is slower than initially estimated, or if business conditions make the whole project nonsense, and it gives the customer natural points to change the direction of the project,” Beck said.

So that clients know the cost of their project, CodeFab includes what Bumgarner calls a “monthly burn rate” for a certain team of people. And because most of its clients expect it, the company includes a clause that states something along the lines of “After three months, this is the set of features we estimate will be in place,” but it tries to avoid any kind of fixed inventory of features, again to allow for the changes that are likely.

Dynamic teams
Another aspect of change within an XP environment happens within the development team. First, with pair programming, team members are frequently rotated to other teams to ensure that the knowledge base is shared among members and to keep any member from holding all the knowledge of a particular issue. This approach also means that delays don’t occur if someone is out sick, or worse, leaves the team midproject. Second, the pair programming technique makes it easier to train new members of the development team. Because the knowledge is spread throughout the team and programming occurs in twos, new members joining the team can be paired off with experienced members to quickly come up to speed.

It’s a matter of discipline
XP has been called a low-key, highly disciplined process. Some proponents say that to really do XP, you can’t pick and choose which practices you’ll follow—you must follow them all to fully realize the potential gains. In a follow-up article, we’ll look at one particular project that CodeFab completed using XP, and we’ll provide some tips for introducing XP into your organization.

Do you do XP?

Have you worked on a team using Extreme Programming? What suggestions do you have for anyone wanting to give it a try? Send us an e-mail with your experiences and suggestions or post a comment below.