When Is Agile Development Not So Agile?

Ann All

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.


Add Comment      Leave a comment on this blog post
Aug 17, 2008 12:40 PM Andrea Andrea  says:
Very interesting information. Thank you for posting. Reply
Aug 23, 2008 12:13 PM Gayle Gayle  says:
We have a similar "lets call it agile" experience. In our case, the development team wasn't commited to fixing all the issues reported in each iteration (which ranged from 2 weeks to 3 months at the end of the release where they basically re-designed software and attempted to fix all the bugs) so we could never take advantage of the quaility improvements agile can foster related to incremental release of working software. To make matters worse, we initially had no business owner commited to the project and the development team had to try and meet a moving target of new requirements very late in the release. The project manager is still calling this "agile" as we move on to release 2. Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.