Friday, January 20, 2006

Article on agile development

I read an article on agile development by Martin Fowler. I thought it was an excellent read. Just to get you excited I have extracted some of the points I found most interesting.

Traditional engineering and software development differ in a significant way. E.g., in building a bridge the design is about 10% of the effort, but in software development it is about 50% of the effort. This changes the nature of the work since design is a much more unpredictable process, requiring gifted (non replaceable) individuals, but construction is rather automated and less demanding on particular skills. Additionally, the requirements for software projects are more liquid making the software design process even harder to predict.

Since the individual developer plays such a big role in a software development the agile processes are focuses on how to mange them and their interactions, as opposed to the traditional approach based on the assumption that the individuals are replaceable parts. Finding a good measure of progress for these processes is difficult, and Martin quotes Robert Austin's conclusion that measurement-based management has to be abandoned for delegatory management.

The unpredictability of software development makes it hard to fix a budged up-front: it is impossible to fix time, price and scope. However, using agile methods, it is possible to allow the scope to vary while keeping the price and time fixed. The success of the project should therefore be measured by how much business-value it provides to the customer, rather than how well it meets its plan.

Martin concludes his article by describing some of the numerous agile methods in existence, this I found of less interest.

1 comment:

Anonymous said...

I think the agile movement is falling into the same trap as SEI with its CMM model did initially. That is claiming improved productivity without quantifying the statement.

If productivity or quality of software development can't be measured, discussions on what methodology suits best are more or less pointless. Everybody can claim their method is best and nobody can argue.

If you can measure the size of software giving numbers to productivity (units per man-month) and quality (customer discovered errors per unit) is fairly easy.

Quantifying the size of software is fairly well established with Function Points (www.ifpug.org) and its ISO Standard.

There is no excuse for software organisations to not measure their productivity and quality. Significant industry data is available for comparison.

regards -Finnur