When business is lousy, getting projects approved and budgeted is challenging. Which means, tough times are good times to be agile. [This is part of the Tough Times series.]

There was a time when you could propose a project that called for so many months of requirements evaluation, so many months of design, and then development and eventually deployment sometime next year. No longer. Anything even faintly smelling of the waterfall model is increasingly DOA.

Because when money’s tight and the future’s cloudy, most executives are going to be focused on surviving the next quarter, not some big win a year down the road. On top of which, the savvy ones know that kind of project is rarely delivered on time.

But just because times are tough doesn’t mean we’re going to stop developing projects. It just means we have to be agile about it.

The classic Agile approach, where you pick two or three key features, spec ’em out with test suites that involve the business side, build ’em and test ’em, and then think about maybe going back for the next two or three, well, that’s starting to look awfully attractive.

By the way, I just ran across Richard Gabriel’s Lessons From The Science of Nothing At All, which gives a good philosophical overview of Agile thinking, aimed mostly at the non-geek. It might be helpful in making some points to your management chain.

You know who this is probably going to hurt? The big-system “blue-suit” system integrators: Accenture, BearingPoint, and their ilk. They, and their customers, have typically lived and died by the big-up-front-requirements paradigm.

Someone needs to figure out some good contract structures to support outsourced agile development.

And for heavens sake, if you haven’t gotten comfy with Agile techniques and thinking, get on it right now.