Over time, a number of software development approaches have been formulated to streamline and effectively manage large projects. As a result, you're faced with a choice when starting a project, do you adopt an agile methodology or develop using a traditional, waterfall approach? Both methodologies have their advantages and disadvantages and while we've been huge advocates of agile in the past, we've realised that waterfall is making a comeback!
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.
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
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.
The project team spends a short period of time (a sprint) 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 sprints. 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 sprints 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 sprint backlog's. Each sprint 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 Versus Time and Materials
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 resources. This makes it a low-risk option for the customer. 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.
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. 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 burndown charts to ensure we complete agile projects in a time effective manner. A burndown chart
is a large graph that displays the quantity of work remaining and the time elapsed since the start of the project. An example of a burndown chart is provided below.
We set our developers a target; to meet their burndown chart every month. As a result, even if a customer chooses a time and materials pricing model there are still goals and targets to ensure a project is completed promptly.
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, we'd love to lend our expertise. Contact us
for a free chat.