Agile methods for package enhancements?

Firstly, it’s worth welcoming back a number of my readers after what I hope was a good Easter week off. The number of readers and page hits was down around a third during last week – but despite that I received a good number of comments on my article Agile vs. waterfall methods.

Not surprisingly to me, the majority of them were from readers who had previously believed that the “waterfall” methods were the only way that a software house could undertake developments safely, and their comments reflected some strong cynicism about the motives of developers and development teams who proposed “Agile” methods.

Further discussions with a couple of those commenting on the post introduced an interesting problem – if a software product has been developed using traditional (waterfall) methods, is it possible to introduce Agile methods for new upgrades?

Unfortunately, as in my original article, I had to revert to using the phrase “horses for courses” in my discussions, as again there is no simple answer – it really depends on what you want to develop, who’s developing it, and the expectations of the management team sponsoring the development.

Surprisingly enough, a brand new module may be just the right project to trial agile methods on – standards for the product will already have been established and documented, and typically the functionality will be relatively small compared to the existing product. Agile methods should allow the product to be seen quickly, and possibly even installed and reviewed early at “warm” customer sites.

However, as in last week’s article, the key to the decision must be the composition and skills of the development team. Not only must they have the necessary technical skills and experience, the team must include someone who understands the requirements in depth – without this latter person, the risk for such an agile development increases dramatically.

It is easy for an agile development to be never ending, with more functionality being identified and added as the weeks progress. Once the original objectives have been met, it is essential to decide on a first deliverable, stop development, and get the new module out to customers.

Once the new module is completed, as with waterfall development, it is also essential to ensure that it is adequately tested by staff external to the development, and supported by comprehensive documentation to allow for easy maintenance by separate support personnel.

However, as noted last week, perhaps the biggest problem is with senior management – are they prepared to take the risk of an agile development?

Amongst my contacts, it is almost invariably the smaller companies that have adopted the agile methods – I know of very few larger application software package developers that have done so successfully. But perhaps that reflects my horses for courses view – perhaps smaller organisations have a level of specific staff experience and knowledge that is possibly missing in larger organisations, their projects tend to be smaller, and their management closer to the development teams. However, as the song goes, I detect that times they are a-changing......