Agile Waterfalls?

There is something of an ongoing debate at present concerning project methodologies between the traditional approach known as Waterfall, and the new kid on the block, Agile, which has become somewhat - dare I say it - trendy. So is it appropriate to change IT development strategy from Waterfall to Agile?

Now there are many different flavours of each of these models, but broadly speaking the principles of each are as follows. Waterfall requires that the project moves through defined stages (broadly - requirements confirmation, design, development, test, acceptance, deployment), whereas Agile is about reducing time into service for software developments by establishing a collaborative relationship between developers and users, and using iterative development techniques to ensure best correlation between requirement and solution. This is normally achieved by time-boxing the overall interval between releases to typically 3 months, and by reducing the project stages to four: release planning, where the approach to the release, including dates, budgets, resources and functionality focus areas, is agreed with the principal business sponsors; the hothouse, an intense, competitive workshop over normally 3 or 4 days to agree the requirements scope and the business case for the release; iterative development, a period comprising typically four or so iterations through the development cycle, delivering successively refined prototypes of the solution; and finally deployment into service.

So should all developments in future move to an Agile model? Agile certainly has some key benefits that are highly relevant to certain project scenarios.

Implementation of new products and services in a fast-moving business can happen more responsively due to the short release cycles. This in turn leads to increased customer satisfaction due to rapid delivery of usable functionality.

There is a closer relationship between business benefit and functional delivery prioritisation, which has to be a good thing. Furthermore, the close co-operation between users and developers leads to a better understanding of the business by the developers, and an increased sense of collaboration and ownership of the solution by the business.

New requirements that are developing during a short implementation timeframe can be accommodated in a method which allows for some flexibility of requirement and prototyping during the development iterations.

However, there are also disadvantages of Agile compared with Waterfall.

Pressure for throughput of development can lead to short-termism of design - a lack of attention to the overall solution architecture and the way that this supports future flexibility and maintainability. Similarly, the rigidity of the time-boxed development cycles can lead to releases being changed in scope at a late stage.

Agile relies largely for its success on a high level of involvement of user communities with the development teams through the iterations, in order to maintain a close link between requirement and solution. This is much harder to deliver effectively where the development teams are off-shore.

Developers need to be experienced and responsible in order to maximise business benefit from the development cycles. This can also be an issue with Indian development teams due to the strongly hierarchical culture in India. Furthermore, it can also increase the average cost per developer day, as it is harder to use more junior resources effectively.

Requirements documentation is often insufficiently precise to form a sound basis for acceptance (or indeed for business process amendment and staff retraining) and can lead to commercial issues between supplier and user, as well as scope creep during development iterations.

Finally, because of the fluidity of requirements and delivered scope inherent in the Agile approach, it is harder to tie a supplier’s contract price to functionality.

In conclusion, it seems to me that where there is the need to provide change on an existing environment, and to keep that change focused on maximum return in a short timescale, then Agile provides a compelling case. However, for major developments - particularly for large scale IT refresh programmes (e.g. billing system replacement) or for greenfield developments for start-ups - there seems still to be a strong case for these being managed in a Waterfall based approach. But there are lessons to be learned here from Agile experiences: large Waterfall projects also benefit from being broken into appropriate phases for frequent delivery of value, from establishing and maintaining a close involvement of the relevant communities within the business, and from a more progressive approach to Acceptance.

Although the advantages of Agile are widely promoted at present, it is also becoming increasingly clear that not every project would benefit from being implemented through wholly Agile techniques.

Tweet