Agile or Waterfall – what should we choose?

01 Jul 2020

They often emerge from IT departments, where agility has been around for years. These practices are applied to both the development process and project management, later extending them to other areas such as human resources or business. This trend makes it increasingly common to find projects that are intended to be managed in an agile way, but is our project suited to be agile?

When a project arises, we must ask ourselves a series of questions in order to determine which methodology is best suited to the needs of the project: does the project have a closed scope? Have we defined well what we aim to build? Is it likely that the project will suffer frequent changes? Can we gather user feedback on our product frequently? Are we willing to tolerate a certain degree of risk in the construction? Do we have a tight Time to Market?

There are two essential concepts in project management: The Iron Triangle and the Cone of Uncertainty.

The Iron Triangle contends that a software project is primarily affected by three variables: scope, cost and time. In order to maintain the level of quality in a project – which should be non-negotiable – changes in one of the variables need to be compensated by adjusting the other two. 

The Cone of Uncertainty determines the level of uncertainty present throughout the lifespan of a project, which decreases progressively as the project develops.

In traditional projects, the theory states that scope and time are usually fixed, making cost the conditioned variable. In practice, the three variables are set in such a way that if a problem that was not initially contemplated appears, it is offset on the basis of over-exertion, taking shortcuts and reducing quality, or with arduous negotiations between the client and supplier to determine who will be responsible for the changes. The uncertainty in the execution of these projects is more limited since the initial phase is designed to conduct an exhaustive analysis of all the functionality that must be developed.

In agile projects, the variable that tends to be tweaked is the scope, conditioned by the time that each of the iterations takes and the available budget. On other occasions, the budget is adjustable, generating a financing model iteration after iteration until the objective is met. The level of uncertainty in these projects is usually very high as no previous phases are established to carry out this analysis. The impossibility of knowing the whole project in detail from the beginning is assumed, and it is expected that the project itself will gain knowledge over time by exposing it to users.

When to use Waterfall?

The cascade methodology is applied in projects with a complicated scope. A complicated project is one on which we have very little uncertainty about what we should do and how we should do it. It requires a great deal of initial planning to enable the inputs and outputs of each of the phases to be defined sequentially: analysis, design, implementation, verification and maintenance, with the exit of one stage being the entry to the next.

The construction of an aircraft can be an example in which Waterfall would be applied. From the beginning, we know the expected result and what must be achieved to create an aeroplane. The steps that need to be taken to go from one stage to another have to be perfectly defined from the beginning in order to obtain the expected result in the desired time. If complications arise, it can be said that they are within ” the expected”.

When can we apply agile practices?

Agile fits in very well in environments with a high level of uncertainty, as its empirical practices allow us to adapt our product to the needs that are gradually being discovered. The centre of any agile project is the end-user, so we can infer that, in order to get the most out of it, one of the requirements is that the end-user is available and involved throughout the project. Are we going to be able to involve end-users in the evolution of our product so that they give us feedback and help us guide it towards something that adds value?

Are we ready to take all these changes and build our product gradually over time as we work out what we need? This clashes head-on with initial planning and a closed scope.

The development of a new social network is an excellent example of a project that should be carried out under some agile framework. Early feedback from users and assessment of the use of its features should determine the evolution of our product, adapting it as we discover what the market requires.

We can conclude that agile projects exist when we do not know enough about what we want to build and we have to progressively discover it; they are projects subject to a great deal of change to which we must adapt (not only in terms of the development team, the project contract must also contemplate this situation in a way that is beneficial to both parties); and are user-centric projects. The user must be at the centre and must be able to be involved as part of the development. 

The benefits of agile practices in highly defined environments may not outweigh the difficulty of adopting their practices in inexperienced teams.

Implementing a project using a pure or “textbook” methodology is hugely complicated. Usually, parts of it are carried out and adapted to the needs of our projects or clients. Still, if we are able to consider these issues before deciding, we can embrace the benefits of the methodology that best suits our needs.