7 min

September 25, 2023

Agile or Waterfall - which methodology to choose?


A key element of an informed approach to management methodologies, is the notion of the difference between the traditional style called the cascade model (Waterfall) and the more flexible approach introduced and described in the Agile manifesto.

Agile and Waterfall are currently the most popular and widely used project management methods.


The former involves breaking down the project process into a number of short phases, enabling the rapid delivery of a partial product. In this way, we have the opportunity to receive a working product at an early stage, which is then gradually developed.


In the second approach, which is more linear, the finished product only appears at the end of the development process. Unfortunately, there is a risk that such a product will not meet the customer's current requirements because it was designed several months or more earlier. This is one of the main problems associated with waterfall.

Let's look at both methods in detail.

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

  1. Top priority is given to customer satisfaction through early and continuous implementation of valuable software.

  2. Changes to requirements can occur even late in its development. Agile processes use change to ensure customer competitiveness.

  3. Deliver functioning software frequently, at intervals of several weeks or several months. The more often, the better.

  4. Business and developers must work closely together on a daily basis, throughout the project.

  5. Create projects around motivated people. Provide them with the necessary environment and support and trust them to complete the task at hand.

  6. Face-to-face conversation is the most effective and efficient way to communicate information to and within the development team.

  7. The primary measure of progress is working software.

  8. Agile processes enable sustainable development. Investors, developers and users should be able to maintain an equal pace of work.

  9. A continuous focus on technical excellence and good design increases agility.

  10. Simplicity - the art of minimising the amount of work required - is key.

  11. The best architectural solutions, requirements and designs come from self-organised teams.

  12. 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 the progress of the project in the right way. These objectives are realised through an iterative approach to work.

The work is divided into short periods (sprints) in which the team focuses on delivering the specific functionality that is part of the final solution. During such a period, a team with diverse skills plans the work, designs the solution, tests it and receives feedback from the client. Only on the basis of the results of the completed sprint does it plan the next one. It is important that each sprint (iteration) delivers functional improvements (for example, a single working feature of the application) that can be evaluated and tested by the customer. By not planning too far into the future, any changes can be implemented and visible in subsequent iterations. This also promotes the detection of programming errors.

Documentation in an agile approach


In the Agile method, the project evolves over the course of the project and the documentation contains only the essential elements that are considered valuable to record. Code is developed incrementally, implemented and integrated, which means that each new feature is designed taking into account the modules already implemented and documented with existing functionality.

Waterfall


At the Symposium on Advanced Programming Methods for Digital Computers, held on 29 June 1956, Felix Torres and Herbert D. Benington first presented the waterfall technique. This popular way of developing software, was described in detail by Winston W. Royce in 1970 in his article 'Managing the Development of Large Software Systems'.

In the cascade approach, we plan the entire project in advance. As in a waterfall runoff, the water moves in one direction, passing through a series of predetermined steps. In this methodology, we rely on executing project activities in well-defined phases that follow one another.

The activities by which the project is carried out from a controlled start to a controlled finish:

  1. 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.

  2. 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.

  3. 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.

  4. Product handover: This occurs when the product under development meets all the initial requirements established at the design stage.

  5. 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 way of working can be effective when you have a strictly defined budget and a more predictable time schedule is needed. In this way, we can successfully implement simple, long-term projects with low demands.

Operating characteristics of the cascade model

  1. Documentation and guidelines are important; it is necessary to write everything down. This consumes a large part of the developers' work.

  2. The next phase of work does not start until the previous one has been completed.

  3. No stage can be skipped.

  4. 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.

  5. It is not possible to return to a previous stage to make changes.

  6. No iteration - there is only one cumulative product development process.

  7. Identifying and fixing bugs only takes place in the testing stage.

  8. 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


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.

Would you like to do a similar project?

Ask for a quote