Waterfall development – When assessing the pros and cons, has waterfall development had its day?

When developing new software, finding the right supplier and the right development methodology is key to having a project that delivers on time, within budget and to the satisfaction of the client. As IT legal professionals, we encounter a range of software development contracts and it is always interesting to see which factors influence clients to opt for either a waterfall development or agile development (or indeed any other form of development) to suit their particular project.

Differences between waterfall development and agile development

We are often asked about the difference between waterfall development and agile development and the pros and cons to each. Obviously, this will depend upon many factors, including the risk appetite of the client, the transparency and the scope of the project and finding the right fit with the right developer.

Let’s start with a summary of the different development methodologies:

The waterfall development model

This model is a sequential style of software development that breaks down project activities into linear stages. These stages are followed successively, where each project phase depends on the deliverables of the previous one, hence the concept of a ‘waterfall’. There tends to be a series of initial phases of analysis and design to establish the full scope of work, before moving on to the build phase, system and user testing, acceptance, go live and maintenance. In between phases, a deliverable is expected and/or a document is signed off. All phases are passed through and completed only once, so all requirements are gathered as much as possible at the start to provide the information in creating the scope of work, plans, schedules, budget, and resources. This type of development is driven by clear planning and delivery milestones, so any changes after the project has started would offset the original plan and require a restart.

This linear methodology has benefits – it approaches the design of the system as a whole; it has a defined scope of work which means that there is clarity and transparency on development resource for the developer and subsequently cost for the customer; progress can be measured in terms of milestones and projects should stay on track in terms of delivery dates.

However, for others (both customers and developers alike) this approach is too structured, defined requirements can stifle innovation, it does not readily permit change and flexibility and as a result, particularly because testing only comes at the end of the project, the development runs the risk of becoming governed by the process rather than the customer’s wishes. Also, there is a danger that the development can end up costing more than originally envisaged; even though stakeholders may be confident that they know exactly what they require, their needs may change throughout the development process. By defining pre-requisites in the beginning, this makes adjusting to new changes more difficult to manage and implement and overall more costly. In the Waterfall methodology, all requirements must be completely documented and approved before any development can occur. This means that a lot of the work is done before moving onto the building phase and of course, this can either be beneficial or detrimental to the project’s success.

The agile development model

This model is based on principles that concentrate more on team-based collaboration, rapid deployment of a functional application and flexible responses to change. Instead of planning for the whole project, it breaks down development work into a set time phase called a sprint with a defined duration, often two weeks. At the start of each sprint, the customer prioritises a list of key deliverables to be developed during the sprint. At the end of the sprint, the team and the customer review and evaluate the work with notes for future sprints.

This method of collaborative working is more customer focused, flexible and empowers teams to think creatively when encountering changes. However, agile development is not for the faint hearted or those requiring fixed cost development! It requires the customer to be full engaged with the project and ‘hands on’, which not everyone wishes to be or has the resources to be. In practice, I have encountered issues in projects where the sprints were not enough to accommodate all the desired deliverables, leading to a product backlog that required further cost to work through.

Conclusion

There is no single methodology that is better than the other or which suits everyone; it simply comes down to the nature of the project, the clarity that you have (or don’t have) regarding the development going forward, attitude to change and budgetary constraints (if any).

Waterfall development is still effective for certain projects that are set within a constrained timeline or budget. The linear structure of waterfall methodology means that customers have a more complete understanding of all software deliverables, thereby setting important expectations from the very beginning. The various milestones and pauses between the conclusion of one phase and the commencement of the next, ensure that each phase is complete and the customer is happy, before moving on to the next. This should result in a customer who is clear about whether the project is on track.

However, for customers who perhaps have less of a clear view as to how the project will develop and requiring a greater degree of flexibility, agile development is an excellent way forward.

Whether you choose waterfall development or agile development as your preferred method of development, making sure that you have legally drafted agreements is crucial. If you need any help with any aspect of this article, please do not hesitate to contact me.

Please visit the IT services section on our website to see all ways in which we can help you in this area.