The first question when considering how a project will be implemented is usually “which development methodology should I use?”. If the aim is to deliver a product or a transformation, shouldn’t both methodologies achieve the same result?
The simple answer is depending on the nature of the project and the method used, the risk of failure changes.
Both methodologies have strengths and weaknesses.
What is Waterfall?
Waterfall is known as the “traditional” methodology. It is a linear approach, which segregates software development into a sequence of the following pre-defined and distinct stages. As this process is sequential, each stage generally finishes before the next one can begin.
- Initiation
- Analysis and design
- Build and Test
- Implementation
- Post-implementation
The strengths of this approach are:
- There is an agreement in advance on what will be delivered early in the project cycle. The full scope of work is known and clients expectations are clear regarding cost, size and timeline.
- Progress is easily measured against the initial scope.
- This methodology stresses thorough record keeping. It allows for the ability to improve upon the existing program in the future. Thorough documentation also mitigates the impact of knowledge loss if team members leave.
There are also weaknesses with utilising a Waterfall methodology, these include:
- All deliverables are based on a requirements document that is created at the early stages of the project which may fall short and cause issues down the line.
- Clients sometimes find it difficult to visualise the end-product., This may result in dissatisfaction as they will not see the final product until it is almost finished (that’s why prototyping is used when needed). Changes can be difficult and costly to implement.
- The gathering and documentation of requirements can be intimidating, as specific details are required early in the project.
- The plan doesn’t take into account the evolving needs of a client. If demands change, the project’s costs and timeline will require replanning.
What is Agile?
Instead of a sequential process, Agile methodology follows an incremental approach. There is a simplistic design at the start of the project, and then the team begins to work on small modules or functional components of the product/transformation. The work is organised in “sprints”; each “sprint” has a defined duration and deliverables at its start. Tests are run at the end of each “sprint”, which allow for bugs to be discovered. If the planned work was not completed, project priorities are evaluated and the information is used for future sprint planning. As work is completed, it is reviewed and evaluated by the project team and the client.
The strengths of this approach are:
- As clients work closely with the project team, they have frequent and early opportunity to see what is delivered. This early feedback often results in clients being happier with the ultimate outcome/deliverables.
- Changes can easily be made to the initial plan if client needs evolve or there are industry developments.
- Testing at the end of each sprint ensures bugs are taken care of and they are not a surprise at the end.
It may sound ideal, but Agile methodology has its weaknesses too:
- There is a high degree of client involvement. It might be perfect for the project, but the client may not have the time or interest to participate.
- As there is no definitive project plan initially, the final product might be different than what was intended.
- Additional sprints (beyond those initially planned) might be needed due to undelivered items and re-prioritisation in previous sprints. Client involvement may result in additional sprints, because of increasing demands. This affects the costs and timeline of the project.
- The full scope of the system might not be considered in the early stages due to the incremental nature of agile methodology. Thus, the system might suffer in overall quality, which can be seen in larger scale implementations and complex integrations.
How to choose between Waterfall and Agile?
We consider the following project factors when evaluating which methodology to use.
| PROJECT FACTORS | WATERFALL | AGILE | COMMENTS |
| Client availability & involvement | Requires client involvement only at initiation, implementation and other key project milestones. | The client is highly involved, and they need to be included throughout the project. | The client might not have the time or interest to be involved. However, client involvement reduces the risk in either model. |
| Scope | Works better when the scope of the project is clear, understood and known in advance. | Welcomes change and works well when the scope of the project is not known in advance or the final product is not fully defined. But, changes come with cost and timeframe implications. | Change is a reality. We should prefer adaptability, where possible. |
| Prioritisation | Typically based on the MoSCoW technique, prioritisation is upfront during the analysis or requirements gathering phase. | Reviewed before each ‘sprint’ to ensure the highest priority features are developed. | Where the priority is likely to change over time, agile is the best delivery approach. |
| Dependencies & complexity | If the deliverable items are co-dependent, waterfall is suitable due to its sequential nature. Also, in the case of large implementations and legacy transformation. | Used if the product or transformation is intended for an area where rapidly changing standards are expected.
|
Adaptability to change is preferable with agile delivery. But, large, complex implementations might end up scattered. Legacy transformations are more likely to have co-dependencies between systems and regression testing is often manual in nature. |
| Team | High degree of hand-off points. | Small multi-skilled and dedicated teams with a high degree of synchronisation. | When different vendors work on various aspects of the project, a high degree of synchronisation may not work. |
| Funding | In fixed-price contracts the risk of exceeding the budget is reduced by getting agreement up front. | Works better in time and materials cases. | When the scope is not clear in advance, fixed price might prove to be difficult. |
| Timeline | If the definition is the key to success for the final product. | If speed and not definition is key to success, then agile is more suitable. Improvements to the product can come later. | Time is not always on the side of changes, where agile is the preferred delivery approach. |