Procurement: Waterfall Methodology vs. Agile Methodology
There are many approaches to delivering a software solution but there are two main categories: waterfall, or traditional methodology, and the more recent agile delivery model.
Waterfall is so-called because it is a linear approach to software development. The sequence of events goes something like:
- Gather and document requirements
- Code and unit test
- Perform system testing
- Perform user acceptance testing (UAT)
- Fix any issues
- Deliver the finished product
In a waterfall development project, each of these represents a distinct stage of software development, and each stage generally finishes before the next one can begin. The waterfall methodology dates back to the early days of data processing in the sixties and seventies.
Agile is an iterative approach to delivering a solution. It emphasizes the rapid delivery of an application. The first iteration is aimed at producing a Minimum Viable Product that covers the basic user requirements. Thereafter, the solution is built out over short time-boxed phases called “sprints.” Each sprint has a defined duration (usually in weeks) with a running list of deliverables, planned at the start of the sprint. Deliverables are prioritized by business value as determined by the customer.
As work is completed, it can be reviewed and evaluated by the project team and customer, through daily builds and end-of-sprint demos. Agile relies on a very high level of customer involvement throughout the project, but especially during these reviews. The term “agile” was first used in the context of software development projects in the early 1990s but is now increasingly used to describe solution delivery with Software as a Service (SaaS).
Despite the fact that Gartner announcing the “end of waterfall” in 2012, and again in 2016, traditional waterfall implementation still remains the most common delivery model for SaaS applications. This methodology continues to enjoy a rather perplexing popularity, perhaps because the process is so straightforward, and many decision-makers prefer the “go with what you know” approach to potentially risky projects. As Gartner and others have shown, however, it is not always optimal.
Waterfall projects require a detailed specification of requirements prior to the start of the implementation phase, and these specifications must go through a lengthy back-and-forth approval process between the customer and the provider before the project can begin. Waterfall projects, therefore, tend to result in a project scope that covers many non-essential or sub-optimal processes and also involves a high degree of customization for requirements that could have easily been covered with a standard (and therefore most cost-effective) solution. In our experience, the average project duration for projects that also include full integration with SAP can range from 8-25 weeks. Investing so much time and money in a solution that cannot be tested for months is risky. Many waterfall projects also go over budget because requirements were not fully covered, or because users found that their actual requirements had changed.
Agile implementation prevents this with its “fail fast” approach, which involves working in short sprints, reassessing and readjusting as needed. With agile, you get fast results and can focus on putting resources towards covering processes and requirements that you really need. If something is not working as expected, or if you find after working with the software that your processes need to be adjusted, you can identify issues and resolve them much faster.
However, 100% agile projects come with risks of their own. Costs and implementation periods are not clear from the beginning, as fixed contracts for agile projects are rare. Starting agile projects can also be a challenge without a clear strategy and an experienced team. With this in mind, JAGGAER has come up with a unique solution to bring all the benefits of agile to procurement without these risks.
Moreover, in some contexts waterfall might still be the preferred option. Here is a brief summary of what you should consider.
Waterfall makes sense if:
- You are replacing an existing solution and the end-users would not accept an MVP
- You know exactly which processes you need to cover, and these processes are up to date
- Your processes require a high degree of customization
- You can afford to wait 6 months to start working with the new tool
Agile makes sense if:
- This is your first time implementing a SaaS solution
- You need quick results
- You would like to get best practice from your vendor
- You’re still working on optimizing your processes
- You aren’t sure if the provider is the right one for your needs and you would like to test the product first
- You want the chance to work with the tool first before deciding on further customizations