When Is Agile Development Not So Agile?

I've written about Agile software development twice in the past month, highlighting its potential to help developers produce enterprise applications that will actually help business users do their jobs.

Many companies struggle with Agile because it's so different from the traditional waterfall method of software development. Now, change wouldn't seem to be a bad thing, considering the low opinion many business users have of enterprise software. But it scares many executives, who prefer to lumber along, doggedly sticking to their usual path, instead of picking up the pace and risking a fall.

But even this change-averse approach might be preferable to making a half-assed commitment to change. That's one of the lessons contained in a CIO.com article about a misguided effort to adopt Agile methods that ended up looking a lot like a traditional waterfall project with a thin veneer of Agile. The result, writes the author:

We had arrived at an "Agile project" in which we did all the requirements up front and committed to them, had a "let's pretend" schedule that allocated time for a year in advance but didn't recognize all the tasks that were needed, and delivered our increments months and months apart.

The author doesn't provide a lengthy strategy for dealing with this problem, but he does advise developers to periodically step back and look for signs that what they are doing is really Agile development. Three key questions:

• Can we easily respond to changing requirements?

• Can we run current builds and see part of the system work?

• Are we working a fairly normal schedule or putting in lots of overtime to meet requirements?

In one of my posts about Agile, I linked to my earlier interview with Doug Mow, senior VP of marketing for Exigen Services, an application outsourcing provider that uses Agile. Mow advises that a close collaboration between development teams and business users is needed with Agile:

... there are situations where the business community simply is not accessible or collaborative. In the end, there's no sense in trying to enforce change if the organizational environment is unwilling to accept it. You'll incur more risk than you've managed to reduce.

Mow also suggests that business analysts can do a lot of the heavy lifting so users won't feel their time is being eaten up with frequent code reviews. And governance models will need to be tweaked, he says:

When you take a look at the whole system, you can sign off on the whole system. But what happens when I sign off on it in pieces? What constitutes signed off and accepted? That becomes a slightly different concept than it was previously.