Extremely Agile Programming

Jens Coldewey is an application development troubleshooter. When he comes onto a project, it's usually engulfed in trouble. By that point, management is often so desperate that it's willing to try almost anything. That's when Coldewey, a Munich, Germany-based independent consultant specializing in banking and financial services, turns to Crystal, one of the new agile development methodologies.

Agile is the label given to a growing number of methodologies with names like Scrum, Crystal, Adaptive, Feature-Driven Development and Dynamic Systems Development Method (DSDM). These new development approaches are based on the premise that if you hire competent developers, presumably they know how to write code. Any problems your developers encounter, therefore, aren't coding issues but organizational and communications ones, and those are what the agile approaches attempt to address.

Coldewey, for example, once jumped into a project that was on the verge of collapse. The team was developing a complex enterprisewide system at a bank and was under extreme pressure to show results fast. In keeping with the Crystal approach, Coldewey spirited away the development team to a remote site. "I told them that the way they work would be up to them. We would develop the process together," he recalls. This alone was a radical departure for the bank.

Then Coldewey handed out two sets of blank index cards, each set a different color. On one set he instructed the developers to write down the things they did in the past that speeded up development. On the other, they wrote things that slowed them down.

"In half an hour, we had a lot of cards of both colors," he says.

After sorting through the cards, they quickly set up a process consisting only of things that sped development while avoiding the things that slowed people down. They followed the process they had just set up to knock out the first iteration of the system within a few weeks and met the deadline.

"We went through this exercise and made changes for every iteration until we had a stable process," which took about three iterations, Coldewey says.

Although the various agile approaches are different, they have some things in common. They're intended to produce software that can be changed quickly, and all specify short iterations and maximize the amount of time spent face to face. They also focus on team morale. "You can't talk about agile methodologies without talking about team morale," says Alistair Cockburn, the originator of Crystal.

The agile approaches differ from extreme programming (XP), although all of them are lightweight methodologies. Lightweight methodologies dispense with much of the software development process overhead that bogs down developers, such as lengthy requirements definitions and extensive documentation. XP, however, differs from the agile approaches by being much more prescriptive, even dogmatic, some might say [QuickStudy, Dec. 3]. XP revolves around 12 practices identified by Kent Beck, author of Extreme Programming Explained: Embrace Change (Addison Wesley Longman Inc., 1999).

Although XP in various forms has been around for several years, corporate IT is only just beginning to consider it. The chief obstacle is that some practices prescribed by XP contradict long-established IT policy. For example, XP specifies pair programming, in which two programmers sit side by side coding at a single workstation. Pair programming seems blatantly inefficient, but a series of studies has confirmed that the approach results in fewer code defects, which ultimately speeds final delivery.

"Pair programming is not as productive initially, but the design happens on the fly and the quality is outstanding. And since we have fewer defects, we're not spending time doing as much bug fixing. So the cost issue is moot," says one application development manager at a major U.S. bank.

XP also requires the customer for whom the software is being written to take an active, ongoing role in the development process—to the extent that the customer is asked to write a test to prove a requested function before it's actually coded. In XP, customers write desired functions on index cards (one function per card). The developers estimate how long it will take to code that function. Based on the estimates, the customer decides which functions to tackle first. Then the customer writes a test, and the developers write code to pass the test. This requires a serious commitment on the part of the customer, but in return, the customer gets exactly what he asked for.

XP's approach to requirements alone saves tremendous effort. "We're talking about a bunch of index cards vs. 100-plus-page requirements documents," says the bank manager. The bank turned to XP to develop a major enterprise document fulfillment system. When a bank client opens an account, the new system automatically generates all the appropriate documents and sends them to the client. In addition to the document fulfillment system, the bank has about 10 applications or reusable components built using XP techniques.

XP isn't perfect, however, and the bank has looked at other agile approaches. "XP doesn't address deployment," says the bank manager. So now he's looking at DSDM, "which has some life-cycle project management," he notes.

Lightweight Programming for Heavyweights

Lante Corp., a Chicago-based consulting company, recently held a conference on XP for its corporate clients in hopes of speeding its acceptance. To make XP more palatable to corporate managers, Lante has teamed with Beck to create what they're calling a one-team approach, explains David Trowbridge, Lante's director of technology. The one-team approach combines an XP development effort with an ROI team that analyzes the business and ranks project requirements on the basis of return on investment.

Lightweight methodologies have been adopted primarily by independent software vendors and Internet start-ups that don't have an entrenched development process. These approaches work best on projects where requirements change quickly and frequently or aren't fully apparent at the start.

Lante, which offers a range of development approaches, from traditional to agile, only recently found a major corporate client willing to try XP.

Similarly, Jim Highsmith, creator of Adaptive, an agile methodology, has started to work with a major pharmaceutical company. "They are kicking the tires. A few companies are using it on Internet projects, but it represents a big change for corporate IT," Highsmith notes.

A move to agile programming, in fact, strikes the most sensitive of nerves: honest communication. For years, corporate IT and users have worked separately. Lightweight methodologies bring everyone together face to face and keep them there.

"Now they have to be honest," says Beck, who set up the showcase corporate XP project at the automaker Chrysler several years ago. "No more padding requirements or inflating estimates." In exchange for honesty, organizations get functionality they need fast. To managers, it's a welcome trade-off.

Radding is a freelance writer in Newton, Mass.

Copyright © 2002 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon