Agile Software Development Gains Momentum in Enterprise

Ann All

Business today demands speed and flexibility in taking products to market. So companies are increasingly offloading commodity computing services to third parties, who can provide them faster, with more flexibility (and often more cost effectively) than internal IT staffs. And guess what? Companies want more speed and flexibility from their internal staffs, too.


So it's no real surprise that up to 46 percent of IT pros recently surveyed by Forrester Research said agile software development was used at their companies. (Thirty-five percent said agile most closely reflected their development process, but the number rose to 46 percent if the definition of agile was expanded to include practices such as rational unified process or spiral, according to an InfoWorld story about the survey.) Unlike the traditional waterfall software-development process, agile emphasizes speedier and more iterative delivery of code, with the ability to make needed changes along the way.


Forrester has been talking about agile development for a while now, in August spotlighting the need for business analysts to familiarize themselves with agile development methods.


Scrum, used by nearly 11 percent of survey respondents, was the most popular agile development methodology. Yet most development teams use several different agile approaches, "embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation," according to the Forrester report. (This makes a lot of sense to me, considering agile's reputation for flexibility.)


Social, Agile, and Transformation blogger Isaac Sacolik contrasts the traditional waterfall method with agile and lists three benefits of agile (which I've seen mentioned elsewhere as well). They are:

  • Less up-front business involvement. Sacolik says development teams can start working on the most critical features and risky technical areas without overtaxing business sponsors for lots of information in the early stages of development. While this is true, agile does require more frequent collaboration between developers and business sponsors during the life of the development process. Whereas waterfall demands heavy business involvement at the beginning and end of the process, business users often provide feedback with each iteration of agile development.
  • Frequent delivery means better execution. Still, the more frequent feedback contributes to what Sacolik calls better execution. The more iterative approach allows for tweaks along the way, something not easily done in waterfall projects.
  • Improved IT/business alignment. This results, says Sacolik, when sponsors prioritize features at the beginning of each iteration. As mentioned above, the development team gets direct engagement from the sponsor, which increases the odds the finished product will more closely meet users' expectations and actually fulfill business needs.


Sacolik's last point about alignment was also mentioned by Doug Mow, senior VP of marketing for Exigen Services, a global application outsourcing provider that uses distributed agile methods, when I interviewed him in 2008. He told me:


The business community can request changes in between each one of these iterations. The business community is watching this system become more malleable instead of more rigid. The changes they request are actually being incorporated. The issues they raise are addressed sooner in the process. Their participation actually has an effect on what happens-this isn't always the case with more traditional development methodologies. You really get a greater degree of alignment between IT and the business.


Not everyone is a fan of agile, of course. When I noted in a post about the cost of failed IT projects that IT Business Edge's development team had recently switched from a waterfall development process to a modified agile one, I got a comment from Aleks Buterman:


... Agile development practices in their pure form (i.e. without proper oversight mechanisms) tend to increase complexity of the overall environment, rather than reverse. The practice of re-use has not been ingrained in the application development community to forestall the duplication (one major driver of complexity) that naturally occurs in a decentralized or federated environments. So I'm glad to see that it's a modified agile that [IT Business Edge parent] NarrowCast has switched to, and it may be of interest to readers to know what other project management structural steel has been implemented to deter complexity.


In addition to a lack of proper oversight mechanisms, resistance to change and strained relations between business users and developers can hamper adoption of agile. As Mow told me, in "situations where the business community simply is not accessible or collaborative ... 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."


IT Business Edge's Knowledge Network has several documents on agile methodologies, including an excerpt from "Agile Project Management" and a description of the modified agile system used by IT Business Edge parent NarrowCast Group.

Add Comment      Leave a comment on this blog post
Jan 28, 2010 9:51 AM Al Gibson Al Gibson  says:

Ann, you should regularly read the Slashdot forums concerning Agile in an Enterprise environment.  Overwhelmingly negative.  Don't believe the snake oil salesmen aka "consultants".

Feb 1, 2010 1:49 AM Robert Dempsey Robert Dempsey  says:

Great post Ann. You list many of the reasons that many companies are implementing Agile in one form or another.

It is interesting that Alek believes that Agile adds process overhead. Most Agile methods, including Scrum, have less process. And, while some methods including Extreme Programming do prescribe a few engineering practices (TDD, continuous integration, etc.), Agile itself does not typically address this, including as Alek mentions code re-use. It is up to the Team to know how to engineer software, not for Agile to tell them how to do so.


Post a comment





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



Subscribe to our Newsletters

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