News Stay informed about the latest enterprise technology news and product updates.

What's your beef with the agile development methodology?

Companies using the agile rapid development methodology are experiencing benefits including quicker return on investment, greater ability to embrace change, better quality and increased productivity. So why aren’t more enterprise organizations adopting the agile process in today’s economy?

According to a recent PPM and IT governance survey of 300 IT professionals, only 30% of enterprise users are deploying agile or other rapid deployment methodologies.

One reason for the low adoption rate could be lack of executive support. The agile development methodology is not the type of initiative that is supported from the top down at most companies because executives see it as costly and complex. Instead, it usually starts in with the application development team, which has become more service- and client-oriented in this economy and knows that the agile process allows them to better collaborate and more quickly meet the needs of the business. With its success comes recognition and support from the top.

Another possible reason for agile’s low adoption rate could be the economic recession. CIOs and company executives see the agile development methodology as a huge investment in money, training and resources.

However, some companies, like IBM, have used the recession as a perfect time to adopt agile. During this global recession, IBM transitioned 25,000 of its developers to the agile development methodology as a way to increase productivity and cut costs.

So what’s your reason for not using the agile process? Is it cost, executive support or something else? Whatever your excuse, there’s no denying the benefits of adopting an agile process — even in this poor economy.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Agile will save money for both the developer and the client why? 1)Stakeholder involvement states each task needs to be broken down to 2 week increments..this means that no task should take longer than 2 weeks if it does the bottlenecks should be identified and cleared up 2)Prioritisation of tasks..most of the time offshore houses will code up something and toss it over the wall back to production. Stakeholders may say this is not what i asked for..if documentation and language translation come last say so in the task schedule..remember this is your money so you need to be pro-active about whats important and what can wait 3)Assignment of resources can be re-adjusted..this happens alot in offshore situations where a new recruit just off the streets doesnt undertand the intricacies of the problem domain..most acute in Scientific, Financial or HealthCare sectors..Having an Analyst that understands the domain is critical to ensuring the requirement from the business requirement translates to clear verifiable testable technical requirement for Further information on when to use Agile Processing Methodology I invite you to look at Martin Gainty (e) 07 Aug 2009