Over the last 15-20 years, the increased use of “Agile” as a project management methodology has caused many companies to move away from the more traditional “Waterfall” methodology and as we head into 2019, as professional project managers we should ask the question: “Is Waterfall Dead?”
Before I answer that, let’s have a quick look at the key differences between the two.
The Waterfall Methodology
Within the Waterfall methodology, projects move along a linear and clearly defined trajectory, like water gushing over a waterfall. There are distinct stages, such as Initiate, Plan, Build and Close and although these stages are often given different names, each stage would normally finish before the next one begins. There are also gates between each stage – for example, Planning must be completed and approved before the Build stage can commence.
In a Waterfall delivered project, success is measured on how closely the project outcomes match the initial requirements and whether the project was delivered within its cost and time constraints.
There are a number of positives for using a Waterfall approach, including:
- The project team and customer can agree on the scope of what will be delivered early in the project life-cycle.
- The solution can be designed completely and more carefully, based upon a more complete understanding of all project deliverables.
- Progress can be easily measured, as the full scope of the work is known in advance and a detailed schedule can be produced.
- Throughout various times in the project, it is possible for only some members of the team to be involved and for others to continue with other work, project related or not. For example, business analysts can learn about and document current business processes while the developers are working on other projects.
- Except for reviews, approvals, status meetings, etc., the customer is not strictly needed after the requirements phase until training and testing is required.
Some of the issues experienced in using a Waterfall approach include:
- Gathering requirements and documenting them in a way that is meaningful to the customer is often difficult. A lot of customers can be intimidated by the level of specific details required with this approach, and normally early in the project. Also, customers and end-users cannot may not be able to visualise a new application simply from reading the requirements document. Mock-ups can help, however there is no question that most end-users have some difficulty picturing these together with the written requirements to get a good, clear picture of exactly what they will be getting from the project.
- With all of the deliverables being based on requirements that were documented early in the project, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement. There is also the possibility that the customer will be dissatisfied with the final product.
The Agile Methodology
“Agile” on the other hand, is an iterative, team-based approach to delivering a project that concentrates on the rapid delivery of a project in complete functional components. Rather than creating tasks and schedules, the time spent on the project is “time-boxed” into phases called “sprints.” Each sprint has a defined duration (usually only days or weeks) with a list of deliverables for that sprint that are only planned at the start of each sprint. Deliverables are prioritised by the customer and if all planned work for the sprint cannot be completed, the work is simply moved into a future sprint.
As it is completed, work is normally reviewed and evaluated by the project team and the customer, through daily builds and end-of-sprint demos.
“Agile” relies heavily on involvement of the customer throughout the project, but especially during these reviews.
“Agile” does provide a number of benefits, including:
- The customer has frequent and early opportunities to see the work being delivered, and to make decisions and changes throughout the project.
- The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.
- If the time-to-market for a specific application is of more importance than releasing a full feature set at once, Agile can more quickly produce a basic version of working software which can be built upon in later iterations.
- The project can often be more user-focused, likely a result of more and frequent direction from the customer.
Of course, there are also some disadvantages:
- The very high level of customer involvement may present problems for customers who may not have the time or interest for this type of participation.
- “Agile” works best when members of the project team are completely dedicated to the project.
- Because “Agile” focuses on time-boxed delivery and frequent re-prioritisation, it’s possible that some items set for delivery will not be completed within the allotted time-frame. Additional sprints may be required which will add to the project cost. Also, customer involvement can often mean additional features are requested during the project, which can add to the overall time and cost of the implementation.
- The close working relationships needed in an “Agile” project are easier to manage when the team members are located in the same physical space, which is not always possible.
Which Is Better For SMB’s?
If you are delivering the project internally, and there are different teams competing for the same resources/staff, then I believe Agile can be a suitable method. Managing resource constraints is easier with short-phased releases that can be started and stopped with less impact. With an Agile delivery model, changes to the project deliverables are expected and accepted as part of the process and this can be handled internally.
If an external project delivery partner is used however, the Waterfall model is much more suitable. This is because the client expects the project deliverables to be met as contracted – they sign a contract which means that when the client wants X, then the project has to deliver X.
For an external project organisation, is also easier to put a structured, Waterfall type project management process in place than an Agile one.
In summary, Waterfall would definitely be more suitable for projects with fixed requirements. A “Waterfall” model is “change-averse” and project outcomes have to closely match the expectations laid out during the planning phase.
However, it might not be suitable for resource-constrained companies. In these cases, an Agile project management process might allow organisations to work within any constraints of time and cost by completing projects in incremental phases.
So Is “Waterfall” Dead?
In a 2016 report, titled “The End of the Waterfall as We Know It”, Gartner pointed out that, “traditional waterfall practices result in inconsistent delivery results” which would indicate the end of “Waterfall”. However, this report only considered Enterprise IT companies, and did not take into account the different needs of Small to Medium Business.
The fact is that “Waterfall” project management is still relevant to Small to Medium Business, especially when outsourcing their project delivery to external project delivery organisations.
Riteway Solutions Group has a tailored a project methodology specifically for Small to Medium-Sized Businesses that combines a more traditional Waterfall approach with certain aspects of Agile to deliver the best outcomes for our Small to Medium Business clients.