Rapids Development

Want Agile and offshore development? You can't have it. Here's what you can have instead.

ManagementSpeak: Recent testing has been positive, and all certified campaign timelines are being aggressively managed.

Translation: We're hopelessly behind schedule, but we think we can meet deadlines by overworking our employees.

KJR Club member Doug Ross tested this translation and confirmed that it fulfills the specifications.

Is Agile agile enough?

I've been an Agile proponent since before we knew to call it Agile (although curiously, I don't seem to have written much about it over the years). I'm not sure it's going to survive its own success, though, for three reasons.

In third place is the inherent conflict between Agile and software engineering. The issue is familiar to anyone who has ever had to support an aging legacy system: The accumulation of small enhancements and patches eventually turns even the best-designed system into a mess.

As all forms of Agile turn big development into a swarm of small enhancements, they all (except, perhaps, eXtreme) put you at risk of starting out that way.

The most common solution is to use the word "refactoring" just as if it actually means something. Usually it means "leaving it up to someone else to clean up the mess."

Bad software engineering isn't inevitable with Agile, just more likely.

In second place is the increasing triumph of form over substance.

More than anything else, Agile is a cultural change -- a redefinition of the relationship between developers and business users. Waterfall methodologies maximized their separation: Users defined their requirements, approved the specifications, then went away while the developers created software which, so long as it met the now-frozen specs, was considered perfect.

Agile, in contrast, emphasized informality and high levels of contact throughout the development effort -- there should be no actual need for User Acceptance Testing because end-users have seen the software in action so often, and have provided so much feedback throughout its creation, that there's nothing new to react to.

That's the idea. Sadly, many of Agile's current crop of advocates are process-izing it excessively, focusing too much on following the steps and not enough (sometimes not at all) on the essential change in how developers and business users collaborate.

The first and most important issue, though, is the fundamental incompatibility between Agile's high-interaction mode of operation and the seemingly unquenchable desire on the part of many U.S. organizations to place a minimum of ten time zones, plus significant cultural differences and linguistic challenges, between developers and business users.

Which isn't fair: These barriers aren't what companies are looking for. They're buying the drug to get lower hourly wages; all the negatives are like the list of unfortunate side effects rapidly narrated at the end of pharmaceutical ads (such as, for example, the obsessive need to place two bathtubs on the beach, out in the woods, or at the edge of a cliff).

Given a choice between Agile's clear advantages over Waterfall methodologies on the one hand (when done right; see above) and the lower price of offshore developers, it isn't hard to predict which will win: Bet on cheap.

And so, with regret, we need an alternative to Agile that provides as many of its advantages as possible while still being workable with offshore development.

What's emerging to address this challenge is something we might decide to

Continue Reading