The Naked CIO: Madness in the method

Waterfall, agile, extreme? Development models are meant to lead to better software for the business. That's not necessarily been the experience of the Naked CIO.

Is everyone confused? Over the past few years, applications development has been blitzed by new, supposedly more effective methodologies. What used to be a standard - waterfall - is now competing against agile and extreme methodologies.

Exclusive Special Report: CIO Agenda 2008

Find out what's hot on the top tech execs' agendas for 2008…

♦ Video: CIO Agenda 2008

♦ Naked CIO: The true cost of IT

♦ Why IT must escape the belt-tightening

♦ Cost-cutting tops CIO priorities

♦ Recession fears hit IT budgets

♦ What governance can really mean to business

♦ The CIO shopping list

Even though I've worked with agile and waterfall, I have yet to make a firm decision on which I prefer. Truth be told, it is the project that determines which is the best methodology to follow.

I have even looked at follow-the-sun methodology, which is where you have teams in different parts of the world to speed up development by using every hour in the day.

This methodology is difficult to manage. But then as I get more experienced they all seem to have their downsides. Waterfall takes too long in the planning stages, especially for large projects, and makes small projects extremely cumbersome.

Seeing the dividends from a long-term project under waterfall can take years, which is never good news for your executive sponsor.

Agile demands that developers know the business or - more importantly - are willing to learn how it operates while they work alongside users in technical groups.

You can develop things more quickly with this methodology but you often have to backtrack to clean up poorly thought-out foundations as a project moves forward.

The bigger the project, the less agile works for me. It is difficult to manage the time-line strictly and costs can run away from you because of the lack of cohesive specification design from the outset. But the agile method can work, especially for smaller more frequent development projects and iterations.

Extreme is a variation on agile and is even less defined. While it is good from a quality and completeness perspective, having two developers develop the same code is very difficult to justify from a resource perspective at any time, let alone with today's labour conditions.

One of the problems with methodologies in general is that you cannot try before you buy and you must commit to a methodology. Choosing the right one is difficult because the purists will tell you this one or that one is best and back it up with some very convincing arguments.

Development methods should follow the discipline of the various methodologies but leave plenty of room for creativity in terms of how you manage the project, account for developer ideas, incorporate appropriate planning and involve the business.

One thing is certain. Whatever methodology you choose and however you decide to customise your own approach, always ensure you spend enough time planning the development.

My experiences - especially the bad ones - have made me a strong advocate of effective, comprehensive and engaged planning of all software development.

All failures in software come down to two things: one, poor planning and, two, a lack of business involvement and commitment.

Whatever methodology you choose must take account of these things.