BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Cost Justifying an Agile Migration

Cost Justifying an Agile Migration

Leia em Português

This item in japanese

Bookmarks

 As companies are experimenting with and examining Agile methods, the cry from the executive suite is “show me the money”;  changing a large organisation’s approach to delivering software is akin to turning an oil tanker – possible but it takes both time and energy.   Management need to be convinced that the change will deliver on one of the two fundamental strategic objectives that drive every organisation – reducing cost or increasing revenue.

In a 2008 article Scott Ambler addresses the motivation behind the cost-justification question, and points to a number of sources which show that

  • Agile approaches are more successful than traditional techniques
  • Agile teams are more productive than traditional teams
  • Agile projects produce higher quality products than traditional approaches
  • Business stakeholders are more satisfied with the outcome of Agile projects
  • Agile projects cost less than traditional development projects

Ambler provides the raw data for the results cited in another article available here.

A lengthy LinkedIn discussion on the topic in the Agile Alliance group   raises a number of points:

  • Measuring knowledge worker productivity is hard at the best of times
  • Because it doesn’t make sense to do exactly the same project twice in two different methodologies a direct comparison is effectively impossible
  • The value of early feedback is most often found in costs saved from mistakes not made
  • Agile projects tend to foster innovation which results in better products which more effectively meet the business needs, and “blow the competitors away”

One contributor to the thread (Steve Gordon) stated:

Along the lines of measurement driving behavior is the issue that the behavior of knowledge workers under agile is more different in kind than in quantity.

Agile can be expected to drive discovery of requirement improvements much earlier and faster than under more traditional approaches (due to feedback on working artifacts early and often, and being open to change). Improving the requirements improves the value of what being produced.

Just measuring raw productivity will totally miss this important effect of agile. Even if raw productivity were to go down a bit (especially during the transition), if what is being produced is more useful and relevant due to frequent concrete feedback, the value delivered to customers can be expected to be much greater.

But, then how to measure the value delivered to your customers? I would think that your customers would know better than anybody else. It also depends on the market. In truly captive markets, quantity delivered might be more important than relevance or quality. In some markets, innovations blow your competitors away much more effectively than more check boxes on feature comparison charts.

Interestingly CNN recognises that Agile is having an impact on management approaches to software development as reported in their article on “50 Who Matter Now – people, products, trends and ideas that are transforming the world of business”:

Agile teams work very quickly -- sometimes in as little as a week -- to create small chunks of code. Once a component is finished, additional features are added, with the process repeating indefinitely. Agile also has a reputation for enabling managers to deliver products on time and under budget, which helps explain why it has become a methodology of choice at companies like Google and Lockheed Martin.

Will this endorsement encourage or discourage the takeup of Agile practices in businesses today?

Rate this Article

Adoption
Style

BT