¿Agile vs Waterfall?

In a world where agility has become the norm for managing software projects, wondering if Waterfall and traditional project management is an option seems unimaginable, however the other day talking to a manager, he asked me if for implementation projects and customisation of a product in customers, traditional project management can be more interesting than using an agile methodology. And the truth is that it seemed like a good opportunity to write about what Agile brings to the table compared to other more traditional models, aimed at a management audience that is not so familiar with agility.

So I want to revisit (albeit not very deeply) the why of Agile and pose some questions for leaders to ask themselves, in order to understand whether Agile is an appropriate philosophy for their contexts.

The first thing to understand is that the Agile movement arose as a response to the problems with traditional project management practices of the 1990s, such as Waterfall. Let’s look at what Agile is trying to solve:

• With Waterfall, handover to the client used to take place at the end of the project, and sometimes at some pre-defined milestones during the project planning phase. The problem is that they realised that this way of working often meant that what had been developed did not meet the real needs of the client or that those needs had changed during development. This caused that entire projects were thrown away after years of development. To address this problem, Agile promotes frequent iterative deliveries that allow to:
  • Deliver value to the customer at an early stage
  • Involve the client during development by asking for feedback to adjust the course, ensuring:
    • 1. that the solution serves the customer’s purposes As an important note, Agile focuses on customer outcomes and sees the software that is delivered as a means to help the customer achieve those outcomes;
    • 2. that the development team does not waste time working on things that do not serve the customer
    • 3. that not too much time elapses between when something is developed and when it is validated by the client, since it has been demonstrated that the longer this time is, the more costly the change will be (intuitively it can be understood as that it is much easier to modify a document that was made yesterday than to modify one that was made a year ago).

How to know if Agile is for your project:

• Are projects perfectly specified from the outset or are they often lacking definition?
• Is there a benefit to my customers if I deliver value as early as possible and then incrementally? Or on the other hand, do my customers only make a profit when all commitments are delivered?
• Is there a learning curve for my customers to use my software that I can mitigate if I deliver the software earlier?
• In the past, when my customer received the software, did it always fit his needs perfectly, or did customers often ask for changes to be made to what was delivered?
• Does the team do work that is then discarded?

In traditional project management there is usually a Project Manager who is responsible for all project management, talks to the various stakeholders and plans how the project will run from start to finish. The development team usually sits below the development team, being the implementers but with little scope to intervene in the definition, as a rule. The problem is that this view assumes that the technical aspects have to be subordinated to the business without taking into account that this may mean that extremely costly solutions are developed or in some cases unfeasible solutions are put in place. This has a direct impact on the business. Agile, however, proposes that the technical and business teams work more as partners, with the idea that the proposed solution satisfies the business while being technically feasible. This requires giving a more prominent role to the engineers in the team which allows them to feel important and part of the project, more committed and to perform better.

How to know if Agile is for your project:

• Do my project managers find it difficult to plan and predict the cost of a project correctly?
• Does the software I develop have a certain technical complexity?
• Does the software sometimes contain design flaws or does it not fully cover certain use cases?
• Does the team seem uncommitted or uninvolved? Do all ideas come from the PM, and if the PM doesn’t come up with something, it doesn’t get done?

In Waterfall project management, the way of working and processes are usually well defined and not questioned or subject to continuous review. When there are problems, traditional approaches such as replacing people or adding more people to the team are used. However, there is ample evidence that adding more people to a project when it is behind schedule tends to delay it further, as the already overstretched team members will have to spend time training the new members, who have a learning curve that can be in the order of months. Agile however puts the focus on the way of working, accepting that it will never be perfect and must be continually reviewed and optimised. This is done using empirical methods in which process performance is measured through metrics, adjustments and changes are made based on these metrics and on the observations of the team during retrospectives in each of the development iterations (which last a few weeks). Considering that we live in an ever-changing world, Agile allows us to focus on improving the process to adapt to new contexts and benefit from new tools and ways of doing things as they appear, as long as they make sense to us.

How to know if Agile is for your project:

• I often experience delays with projects and I am not sure why?
• Do people in the team frequently complain about the way of working or the process?
• Has my process undergone few changes in recent years?

Competition for engineers is currently quite high and in recent years this trend is only increasing (if you talk to CTOs and technical leaders they will probably tell you that this is one of their biggest concerns). This allows developers to become increasingly demanding and selective when it comes to joining a company. Salary, while critical, is not the only reason a developer moves, things like technology, career development opportunities and teamwork are also taken into account. It is true that there are quite a few developers who are not very satisfied with Scrum as a way of working, but it is hard to believe that they would be motivated to go to a company that uses the Waterfall of the 90s. Of course, the world of developers is heterogeneous, and it is difficult to generalise, but I would say that most senior (and not so senior) programmers will be interested in knowing the methodology they are going to work on. And I’m sure there will be others who don’t care, but in that case we should ask ourselves why there is a lack of interest and whether these are the profiles we want for our team.

How to know if Agile is for your project:

• I am concerned about attracting talent, and I am aware that developers increasingly have more choice and demand more than just a good salary?

It may also be that the organisation in this situation has adopted some Agile framework, such as Scrum, but there is a feeling that there has not been the improvement that was expected. This can and does happen for a multitude of reasons such as: lack of people in the team who really understand Agile, adopting an inadequate framework for our reality (Scrum is very widespread but it is not the only alternative and often not even the most recommended, you can read about different alternatives here), implementing practices without adopting agile values and principles (i.e. not changing the mindset), lack of understanding and support from leadership, etc.. If you are more interested in understanding why Agile doesn’t always work you can read this post.

In conclusion, Agile is intended to embrace changes in the scope of the project and involve the customer during development as the best way to ensure that the result obtained is optimal (known as co-creation). It also highlights the importance of technology and business working hand in hand as a way to get the best results at a controlled cost. And it promotes a new culture in which continuous improvement allows us to optimise the business while caring for the happiness of our customers and our teams. However, Agile is not perfect either, and in recent years more and more initiatives have emerged that talk about the many problems encountered in its implementation and how to evolve the philosophy using the learnings of the 20 years since the Agile manifesto was defined.

If you are faced with the dilemma of deciding which working methodology to choose, my recommendation is to talk to someone with experience before you jump into choosing one based on unsound criteria. Inappropriate methodology can put a spoke in the wheels of a team’s performance.