• ELECTRICAL CABLING AND WIRING -...
• Technical Consultant
• Senior Flash Developer / ...
• Project Analyst
• Security Engineer

Extremely agile programming

Alan Radding, Information Age

18/06/2002 17:13:15

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 German independent consultant specialising 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 organisational 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 enterprise-wide 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 colours," 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 maximise 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. XP revolves around 12 practices identified by Kent Beck, author of Extreme Programming Explained: Embrace Change (Addison Wesley Longman, 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 US 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 fulfilment 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 fulfilment system, the bank has about 10 applications or re-usable 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 heavyweightsTo make XP more palatable to corporate managers, consulting company 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 analyses 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 tyres. 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, organisations get functionality they need fast. To managers, it's a welcome trade-off.

Agile or nonagile?

Is your organisation a good candidate for using one of the agile programming methodologies? The answer may be yes, if you have:

-- Uncertain or volatile requirements

-- Responsible and motivated developers

-- A customer who understands and will get involvedOn the other hand, more traditional, predictive approaches are indicated if your project involves:

-- More than 50 developers

-- A fixed-price or fixed-scope contract- Source: Martin Fowler, "The New Methodology", www.martinfowler.comAgile programming systemsFor more on agile programming in general, see the Agile Manifesto and "The New Methodology" by Martin Fowler, at www.martinfowler.com/articles/newMethodology.html.

Extreme programming

Built around 12 basic practices ranging from pair programming to frequent refactoring, this approach is more prescriptive than the others. For more information, visit www. extremeprogramming.org and www.xprogramming.com ScrumBased on the empirical process control model, Scrum programming relies on self-directed teams and dispenses with much advanced planning, task definition and management reporting. To learn more, visit www.controlchaos.com or read Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle (Prentice Hall PTR, 2001).

Crystal

This approach empowers the team to define the development process and refine it in subsequent iterations until it's stable. To learn more, visit http://crystalmethodologies.org/ or read Agile Software Development: Software Through People, by Alistair Cockburn (Addison Wesley Longman, 2001).

Adaptive

Based on adaptive rather than deterministic theories, this approach offers a series of frameworks to apply adaptive principles and encourage collaboration. For more information, visit www.adaptivesd.com or read Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, by James A. Highsmith III (Dorset House Publishing, 2000).

Feature-Driven Development

This model-driven, short-iteration process is built around the feature, a unit of work that has meaning for the client and developer and is small enough to be completed quickly. To learn more, read Java Modeling Color With UML: Enterprise Components and Process (with CD-ROM), by Peter Coad, Eric Lefebvre and Jeff De Luca (Prentice Hall PTR, 1999).

Dynamic Systems Development Method

Conceived as a methodology for rapid application development, DSDM relies on a set of principles that include empowered teams, frequent deliverables, incremental development and integrated testing. For more information, visit www.dsdm.org or read DSDM: The Method in Practice, by Jennifer Stapleton (Addison Wesley Longman, 1997).