Take accounting, for example, where debits always have to go on the left, credits always belong on the right, and if transactions aren't ACIDic (atomic, consistent, isolated, and durable) the books won't balance. Given that the field hasn't changed all that much since Pacioli invented it 500 years ago, whatever it is you're developing for the accounting department will probably last a while.
Then there are instances that depend on complex business logic. A secret of which we dare not speak is that, when complex business logic is involved, business managers rarely take the time to turn their ad hoc decision making into consistent, teachable rules. Usually, it takes a strong business analyst from IT to untangle the threads.
But agile takes business analysts out of the loop, preferring direct interaction between developers and users. Complex business logic inevitably pushes these types of projects in a waterfall-ish direction.
For that matter, when IT untangles complex business logic and codifies it in an application, it automatically makes the business more integrated and consistent. This, interestingly enough, makes the business less agile by definition, because coding business logic into software is very much like drafting business decisions into the "policies and procedures manual." Anything that's official is harder to change than something that's improvised on the spot.
The code-reuse conundrum
Here's a paradox: When developers can call an existing, well-tested module instead of having to write new code, they'll finish a given assignment faster. That makes them more agile, doesn't it? Well ...
Sure, so long as (1) they aren't the one who has to write the reusable module in the first place; or (2) the module fits their situation well and isn't a rounded hole into which they have to push their oblong peg.
Writing reusable modules takes more time and care than writing something for one-time use. "More time and care" doesn't sound very agile, does it? I didn't think so, either. It's a short-term/long-term issue, only agile really should be about being good at the short-term stuff, shouldn't it?
As for the pegs-and-holes situation, it's similar to what businesses face when implementing ERP suites. Software is simply an opinion of how business should run. However, when a business manager's opinion about how to run their part of the corporation differs from what the ERP system's designers had in mind, implementations become chancy. Adapting the system takes longer; as a result, everyone ends up having to change their procedures to do what's natural to the software.
Other than the price tag, there's no difference between "reusing" code embedded in a commercial ERP suite and reusing internally developed code. Either way, business managers either share the software designer's opinion or have hard decisions to make.
Moving IT beyond agility
Where does this leave someone trying to take IT into the next generation?
Every business of any size and age has some areas subject to rapid and unpredictable change, and others that are, for the most part, stable. IT has to be able to support both, which means using agile and waterfall techniques based on what the situation demands, not personal preference.
In other words, next-generation IT has to be something even more difficult than agile: It has to be versatile.
This story, "End the holy war over agile development," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.