With waterfall, we realize too late that things that we thought that are going to work didn’t work as planned in the installation stage, or even later in the production stage. Performing those changes implied a whole lot of steps, and course correction was slow and painful.
Software evolves quickly, and the needs of our clients might change in the middle of the design. That’s why we need a more agile and flexible methodology other than waterfall. The quicker we get feedback, the quicker we can adapt and deliver the exact expectations of our customers.
This is exactly what the Agile methodology is for. Agile seeks to deliver the software in multiple releases, each one going through a set of tests and feedback in order to obtain it more quickly and make changes and course correction in a quicker and more agile way.
Agile was a game changer, but it generated conflicts between operations and developers.
Deploying releases more frequently can be unstandardized and different every time, if a different engineer performs the deployment. Let's say you have a deployment at night. If the person who is deploying in the morning is a different engineer than the one that performed the last deployment, they could have a completely different way of deploying the code to production. These types of things generate discrepancy and can cause problem. For example, if something happens and it needs to be rolled back, a different person rolling it back might not know what the steps that were taken in deployment were in order to roll back the changes.
With these releases, system availability can be affected unpredictably. Operations engineers are measured by the stability of the systems that they are managing, and it's in their interest to keep it that way. Deploying unpredictable changes to production is something that they want to avoid. Developers, on the other hand, are measured by how quickly they can put their new changes, features, and releases into production. You can see how these two teams have completely opposite goals, and they almost have to fight each other to fulfil them.
Different goals across teams isolates each team from another. This creates silos, and throws the problem or app over the fence. This develops into a non-collaborative working environment, where everybody blames one another and things move at an even slower pace, instead of solving the problem.