7 min
October 22, 2023
Agile or Waterfall - which methodology to choose?
In today's dynamic world of project management, choosing the right methodology is a fundamental decision that can determine the success or failure of an undertaking. For years, two main philosophies have clashed in the battle for efficiency: the traditional, sequential Waterfall model and the flexible, iterative approach known as Agile.
Are you wondering which methodology to choose for your next project? Do you need the rigorous planning and predictability that Waterfall offers, or greater adaptation to change and continuous collaboration, typical of Agile? In this article, we will dive into the world of these two popular approaches, analyzing their key features, strengths, and limitations. We will help you understand the differences and make an informed decision on which methodology best suits the specifics of your team, project requirements, and business goals.
Listen to the audio version of this article.
Agile or Waterfall?
Agile methodology, in short, involves dividing the project process into many short stages, which enables rapid delivery of a partial product. Thanks to this, we have the opportunity to receive a functional product at an early stage, which is then gradually expanded.
In the second approach, which is more linear, the finished product appears only at the end of the development process. Unfortunately, there is a risk that such a product will not meet current client requirements, as it was designed several or a dozen months earlier. This is one of the main disadvantages associated with Waterfall.
Let's take a detailed look at both methods.
Agile
Agile is a project methodology that was described in 2001 in the 'Agile Manifesto', which served as a declaration of common principles for new software development methods. The agile way of working is not only used in the IT industry, but also in the management of other projects.
The manifesto included 4 core values, 12 agile principles and a description of the key phases of the project process.
Agile core values
people and interactions over processes and tools,
working software over extensive documentation,
customer cooperation over contract negotiations,
reacting to change over implementing a plan.
The Twelve Principles of the Agile Manifesto
Top priority is given to customer satisfaction through early and continuous implementation of valuable software.
Changes to requirements can occur even late in its development. Agile processes use change to ensure customer competitiveness.
Deliver functioning software frequently, at intervals of several weeks or several months. The more often, the better.
Business and developers must work closely together on a daily basis, throughout the project.
Create projects around motivated people. Provide them with the necessary environment and support and trust them to complete the task at hand.
Face-to-face conversation is the most effective and efficient way to communicate information to and within the development team.
The primary measure of progress is working software.
Agile processes enable sustainable development. Investors, developers and users should be able to maintain an equal pace of work.
A continuous focus on technical excellence and good design increases agility.
Simplicity - the art of minimising the amount of work required - is key.
The best architectural solutions, requirements and designs come from self-organised teams.
At regular intervals, the team analyses opportunities to improve its performance, and then fine-tunes and adjusts its activities according to the lessons learned.
Stages in the design process
planning - gathering and analysing customer expectations, budget information, developing product concepts and assumptions
designing - defining the key elements of the project, the manner and deadline for their implementation
development phase - programming, actual work on the project
testing - checking product compliance with assumptions and expectations
implementation - handing over the product to the client
feedback - feedback from the client to the development team, allowing the team to improve its work
Iterative approach
In the Agile approach, the team's goal is to create value by receiving feedback and planning project progress in the right way. These assumptions are implemented through a cyclical approach to work.
Work is divided into short periods (sprints), during which the diverse-skilled team focuses on delivering specific functionality that is part of the final solution. During such a period, the team plans work, designs the solution, tests it, and receives feedback from the client. Only based on the results of the completed sprint is the next one planned. It is important to deliver functional improvements (for example, a single working application feature) in each sprint (iteration) that can be evaluated and reviewed by the client.
By not planning too far into the future, any changes can be introduced and seen in subsequent iterations. This also facilitates the detection of programming errors from the very beginning of the project to its end.
Documentation in an agile approach
Within the Agile methodology, the project evolves during its duration, and documentation contains only essential elements considered valuable to record. Code is created gradually, implemented, and integrated, meaning that each new function is designed considering already implemented modules and documented with existing functionalities in mind.
Waterfall
At the Symposium on Advanced Programming Methods for Digital Computers, held on June 29, 1956, the Waterfall technique was first presented by Felix Torres and Herbert D. Benington. The term "waterfall," associated with IT, refers to a popular software development method described by Winston W. Royce in 1970 in his article "Managing the Development of Large Software Systems."
In the Waterfall approach, we plan the entire undertaking upfront. Similar to a waterfall, water flows in one direction, passing through successive, established stages. In this methodology, we rely on performing project activities in strictly defined, sequential phases — which is the main difference between Agile and Waterfall.
The activities by which the project is carried out from a controlled start to a controlled finish:
Requirements gathering and assessment: The stage of gathering information (from clients, stakeholders) on the functional, systemic or technical features that will be used in the project.
Design: As in the flexible approach, here too the most important functions of the product or service are determined in consultation with the client, also in terms of user experience.
Testing: The testing stage to assess quality and performance. If the product meets the requirements, it receives the client's approval. If errors are found, the project team fixes them before the product is delivered.
Product handover: This occurs when the product under development meets all the initial requirements established at the design stage.
Maintenance / upkeep: Once the final product is received, the client may request additional changes (which will extend the time to finalise the project and increase costs).
The Waterfall methodology is based on the meticulous execution of a predetermined plan. Within this methodology, the timetable must be strictly adhered to and detailed documentation of activities must be maintained. An electronic workflow, for example, can be used for this purpose. The Waterfall method also assumes a specific budget, which cannot be exceeded. A team working in this way has to be limited and there is not much room for improvisation, room for change and room to react to the current situation.
The cascade working model is effective when you have a strictly defined budget and a more predictable timeline is needed. In this way, we can successfully carry out simple, long-term projects with minimal requirements.
Operating characteristics of the cascade model
Documentation and guidelines are important; it is necessary to write everything down. This consumes a large part of the developers' work.
The next phase of work does not start until the previous one has been completed.
No stage can be skipped.
If the product requirements change after consultation, the client must formally notify this and the task list will be adjusted. This extends the completion time of the entire project.
It is not possible to return to a previous stage to make changes.
No iteration - there is only one cumulative product development process.
Identifying and fixing bugs only takes place in the testing stage.
The customer is not involved in the creation of the product once the list of tasks and requirements has been established. It receives the finished product for testing.
Real life example
We are implementing new layouts for the entire website for company X. The project is carried out in a cascade method. 3 months into the project, the client presents a new vision of the functionality and appearance of the shopping cart.
In practice, this means:
a re-examination of the project, which also involves costs on the client's side
recalculation of the project value
reworking, establishing and documenting the next project steps. With this method, it is often the case that the entire project has to be started from scratch.
This situation is not comfortable either for the client or the developers working on the project.
In an agile project, this type of change would be natural, carried out smoothly in the next iteration. The Agile model presupposes evolution and change during, rather than after, a fully completed project.
Currently, it is only recommended to use the cascading method in three situations:
1) When there is a client who requires transparency in the work being done and the project is due for completion within a certain timeframe.
2) When there are qualified managers present.
3) When carrying out a project that has no competition in the market.
