Agile vs. Waterfall: strengths, weaknesses, opportunities and threats

In the past years, software development practices have seen a dramatic shift from the traditional model to the agile, collaborative way of working. Even though they were initially regarded with caution, even distrust, the Agile approaches for managing projects projects are, according to one of the latest statistics from Project Management Institute, one of the main factors contributing to the increase in the project rates success (see  PMI). In the followings, I will briefly go through the strengths, weaknesses, opportunities and threats of the two models.

Waterfall is a structured, segmented and easy to understand model, with clearly defined phases and fixed deliveries. The entire work is well documented and usually, the projects have development costs that are easy to estimate. These strengths trigger also a set of opportunities. For example, the existence of a formal and solid documentation will ease the knowledge transfer to the newcomers, giving them a good start and a way to fill in their knowledge gaps.

However, the weaknesses of the Waterfall model outweighs its advantages. Here, one can always name the time spent in each stage of the process and the effort dedicated for trying to overcome the future bugs and errors. Nevertheless, in a Waterfall model, the teams are quite separated, focusing each on a specific part of the system and not collaborating too much with each other. Same goes for customer interaction: this one is less likely to be involved in the design and will have no opportunities to influence the development process. In terms of design, if proven wrong or, simply, not working, this will be difficult  and very expensive to be changed towards the end of the project. Also,  Waterfall methods are ineffectively using the resources (for example, the testers will be held on idle until the actual testing phase begins) and is prone to long feedback loops and error correction procedures.

On the other hand, Agile methodologies have a longer list of strengths and opportunities but, unfortunately, do not lack weaknesses and are still subjected to threats. Starting with the strengths, the Agile projects are centered more around functionality than around “nice to have” features. Besides, their high flexibility allows the developers to add small, incremental changes and constantly tailor the project to the customer’s needs. The small development patches and short cycles require early and continuous testing, which leads in the end to fewer bugs and implicitly, to a better product.

When it comes to communication, an Agile way of working triggers constant interaction among the teams and among the stakeholders. The critics of Agile (if any left!) will eagerly turn this into a weakness (as meetings require time), but overall, the information spreading is faster and more effective as everyone is “on the same page”.

In terms of documentation – Agile projects will not deliver extensive documentation. I have not met too many developers who like documenting their work and I also believe that a well written and working code is self explanatory. Also I think it is an advantage – both time and energy wise – that effort is spent in a different direction rather than on writing documents that very few (or none!) will read.

Regarding the weaknesses of Agile – I would say that it does take time until people move from simply understanding Agile to actually practicing it. Apart from this, I found many statements regarding the drawbacks Agile has when it comes to geographically distributed teams. From a personal perspective and as being part of a project in which the teams were not always co-located, this was rarely a problem. There were indeed issues with the synchronization (sometimes not all the resources were available or it was difficult to have all the teams working at the same pace), and maybe extra work was required to coordinate all the teams, but in general, everyone perceived it as a joint venture and made efforts to overcome the distance.

Unfortunately, an Agile setup will not run smoothly from the very beginning and, for the organizations that have just started to adopt Agile, that is when the most threats show up: as an example, for the persons who have been working in the organization for a longer timer, the redefinition of roles together with the new ways of working might lead to confusion, misunderstandings and, inevitably, to a resilience towards change: comments and beliefs such as “it was better before”, “we talk about how to work but no-one is actually working or getting things done any longer” are quite common in the early stages of such shifts. Besides this, I would add that the planning and estimation is difficult at the beginning.

When it comes to opportunities the biggest I’ve seen (and experienced) was that, team members have the chance to work with different areas and to stretch their competence and abilities. Of course, this may lead to fewer experts/specialists but I personally see no better way of fostering learning among employees or encouraging them to thrive on challenge.