The waterfall methodology is a linear approach to software development. Initially, the project requirements are comprehensively scoped out. This is critical in a waterfall project as the final software will reflect the requirements outlined at the beginning. Once completed, the software will be designed, developed, tested and deployed. Each of these is a distinct stage in the process where the previous stage must be completed before the next can begin. This means a project's timeframe is generally longer when using the waterfall methodology but at the end of development you're left with a polished, final version of the software.
In contrast, agile is an iterative approach to software delivery that builds incrementally from the start of the project. It emphasises rapid delivery in complete functional components. These are separated into sprints and prioritised based on their importance. The focus is on the end user. Through early and continuous delivery, agile teams aim to include the customer and end user in the process. For a more detailed analysis of the agile methodology check out this article.
The best fit will depend on your project and personal preference. To ensure you're well informed, we've included the top risks applicable to software projects and the development approach that may mitigate that risk.
In an agile project, both the customer and developer face risks. The customer is likely working off a time and materials pricing model (to be discussed below), meaning the price can fluctuate. The projects timeframe is also uncertain as requirements are susceptible to change. As customer involvement is a prerequisite for agile development, there is a high risk that the response time from the customer may be slow and impede timeframes. However the customer is able to decrease the potential for poor end user engagement as user acceptance tests, which will either validate or modify the project are conducted regularly. The developer also carries risk. Due to the flexibility of an agile project, it's difficult to accurately allocate resources. Development teams may spend more or less time on a project than initially anticipated which may impact future projects in the pipeline.
To discover more about how we work with agile, read our Way of Working
In a waterfall project, the risks faced by both parties differ. Fixed pricing and timeframes help create certainty for the customer. However developers risk underquoting a project. As mentioned above, the customer is capable of conducting user acceptance tests and modifying a project when adopting the agile methodology. This is not the case for waterfall development. As a result, customers risk poor end user engagement, or future costs adding/modifying features. The nature of the methodology means that neither party risks scope creep. There are also risks around the sequence of processes. Because testing only occurs after development is completed, there is an added element of risk. The testing phase is the first event for which timing, storage, input/output transfers are experienced as distinguished from analysed.
Waterfall
One of the greatest advantages of the waterfall approach is that development teams and customers agree precisely what will be delivered at an early stage. This removes the risk of scope creep and allows developers to accurately forecast the project completion date. In addition, a customer presence is only needed at the beginning of the project (when scoping the requirements). The waterfall methodology also allows for measurable progress. Because the entire project is scoped out, it's easier to determine where you are in the project's lifecycle. It removes the risk of a disjointed application as it adopts a wholistic approach to development.
Unfortunately it also means projects aren't as flexible. A comprehensive list of requirements are formulated at the beginning. Consequently it becomes much more difficult to alter or add features once the design stage has begun. There is minimal customer collaboration as the customer does not play an active role in development once the requirements backlog has been completed. The fact the customer only receives a final product limits the opportunity to receive user feedback during development. However if you know what your end user wants, waterfall is often an effective choice.
Agile
The project team spends a short period of time (a iteration) building a small part of the project to integrate into the application. This allows the team and business owner to build, measure and learn from iterations. The customer has an early opportunity to see completed work and is able to make changes throughout development. However, this opens the door for scope creep. Between the scoping phase and the completion of the development phase, customers will often want to include new features in the project. These features aren't planned or assigned to iterations and are not included in costing/time estimates.
Agile allows developers to prioritise certain features, hence an MVP (minimum viable product) can be produced quite quickly. The customer can then begin planning further iterations to improve on the MVP after user acceptance testing (UAT) is completed. The diagram below is an overview of the software development process for an agile project. The product backlog is completed and subsequently broken down into iteration backlog's. Each iteration is deployed to beta and development environments. Once the project's tests pass, it can be released to a production environment.
A waterfall project is more linear than the graphic above. Rather than including a feedback loop where you iterate to the next sprint, everything is completed based on the product backlog and deployed to the testing environments before it's deployed to the production environments.
Fixed Price Fixed Scope (Waterfall) Versus Flexible Scope or Flexible Time (Agile)
There are two commonly used methods for pricing a project. A development company can either offer a fixed price or a variable price dictated by time and materials. As mentioned above, the waterfall methodology lends itself to fixed pricing. The model is ideal for small and medium level projects with clear and well-defined requirements. With a fixed pricing strategy the customer knows exactly what the project will cost, allowing them to accurately allocate budget. This makes it appear low-risk option for the customer with well defined requirements. However, the risk around User Acceptance testing and unknown unknowns e.g technical debts, decisions and shifting perception means that the developer has to factor in this risk to the price on top of their estimations. The pros and cons of the fixed price model are outlined in the table below.
The time and materials pricing model is most beneficial for customers that want a flexible and agile project. The model allows software providers to adopt an agile methodology. At the beginning of the project, estimates are given based on how much the developer believes it may cost. However the final figure is calculated at the end of a project, and will reflect the time spent in development and any materials used. This is scary! However, there is a solution. If the time is fixed and everyone agrees upon the fixed time the scope can be varied back to ensure the most value is being delivered within the timer period. This means the scope can adjust per iteration. New items can be added or removed.
Requirements can change frequently without the development company attempting to forecast these changes at the beginning of a project. The risks are low for a software provider under this model as their time is compensated so they aren't motivated to multiply or inflate estimations. However, the customer has a greater degree of control. By keeping the requirements relatively similar to those scoped at the beginning of the project, the price won't fluctuate too much from any estimates given. Keep in mind that if new requirements need to be added, then this can be done at the customers request. WorkingMouse utilises the agile scrum development methodology. This enables for a backlog of requirements to be ordered by priority with time. This enables the customer to see and choose what is of value for the next iteration. The image below represents what a scrum backlog looks like. The items can be prioritised up and down. They also usually have time estimations if they where originally estimated. This enables the product owner and team to decide value in moving requirements from the backlog into the next iteration.
Each methodology has its own strengths and weaknesses. Early on, WorkingMouse essentially operated as an agile evangelist. We believed there was one right answer when it came to a development approach and it was agile. However we've grown since then. In doing so we've recognised that waterfall is a valid development approach with its own advantages. We've allowed our partners to decide which methodology they would like to use, presenting the advantages and disadvantages of each approach.
If you're struggling to decide, or have a question we'd love to lend our expertise. Ping us for a chat with your questions.
