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 call “Rapids Development.” No, not Rapid Application Development (RAD). While also speedy, Rapids Development gets its name from what rapids are in a river — miniature Waterfalls.
Rapids Development more or less follows the Waterfall model of separating requirements definition, specification, coding, testing, and production into separate sequential phases, but it makes them very, very short phases. Ideally, the entire cycle occupies three months or so; alternatively, following advice given in this space a very long time ago, two teams, each following six-month cycles, work three months out of phase with each other to still provide a new release every three months.
Rapids Development (there really should be a TM superscript after it, shouldn’t there?) has a number of attractive qualities. It solves the software engineering issue (to the extent any practice can solve it). It provides the same fast delivery and the opportunity to adjust to changing circumstances Agile delivers.
And, because it preserves Waterfall’s separation of duties, Rapids Development easily adapts to offshore development.
Which isn’t a plus for American developers, but is a plus for their soon-to-be-former employers.
What Rapids Development doesn’t solve for is Agile’s culture change … the shift from formal interviews, documentation of requirements, business-user sign-off of specifications they don’t understand in the slightest but have to sign off on anyway or the project stalls and all the rest of it, to actual day-to-day collaboration.
Rapids Development offers nearly everything a business could want … everything except what matters most.
What do you want from me, perfection?