Waterfall could be better than agile(sometimes)

Sounds crazy, right? How could that possibly be the case? Before I continue, I need to say I',m doing agile for +14 years non-stop, and I sincerely believe Lean / Agile does good things. However, like everything in software, there are trade-offs. You might be thinking(Crazy Brazillian), and Agile is about incremental, fast feedback cycles, effective learning, and practical, tactical way to avoid waste and risk by shipping code to production often. How could that be bad, after all? To understand the hidden trade-offs here, we need to understand what is behind the principles of Agile. Hold on bozo; there is no such thing as assumptions behind principles. Recently I was challenging microservices. Today is Agile, tomorrow I don't know but something else might come up. To some degree, I feel agile needs to be challenged because last time I did it was around 2015. It's healthy to disagree if it helps to harden your decisions and as the whole team/company you take better decisions. My goal here is not to make a flamewar against Agile but say that we need to think all the time and understand there is no one size fits all even for things like Agile, Lean, DevOps, etc. So without further due let's get started. 

Agile Manifesto

The agile manifesto talks about the principles, not the process, not the methods. If you analyze the declaration, we could easily group the declaration in 2 groups of interest.  


Assumptions behind the Principles

  1. Are you going to change? Belives and Org-Structures? 
  2. Incremental work as value (It's about coupling, Can you decouple?)

Before I elaborate more, let's define what I mean by Increment. The Increment is a piece of software, module, service, component. It does not matter. You chose to release the Increment by steps, let's say, every one, two, four weeks, or during two years on quarters release, it doesn't matter. 

#1 it's already a big issue. People in companies often don't want to change. Because they often want to do Empire building, and there is HIPPO dictating all product decisions. Agile will only work if you're going to change your beliefs system and your organization charter. So basically should we change or surrender? I always think we should change and improve things, in other words never surrender but maybe some changes won't happen right now so why bother? Maybe save the energy to a future battle? 

#2 Here is the catch. Most of the time, incremental work makes sense; however, not always. Sometimes we are making work incremental just for the sake of having the work incremental not because we are getting benefits from it. Quickly, we could architect things both in Business/Product and Tech the wrong way, which would explain why breaking into increments is a wrong move. So let's understand the properties of proper Increments: 

  • Real incremental benefit(value on each increment release) 
  • Ability to discard future increments(some increments might be optional)
  • Ability to change future increments direction

So not all increments are created equally so that a Bad increase would look like this:

  • There is no real benefit on each Increment (only when you have all things there, it can be used or will have value). 
  • Therefore there is high coupling on the product/system. 
  • No ability to drop anything or change direction. 

Agile works better with loosely coupling.

Most of the time, we can architect products and software in a way that can have benefits working on incremental ways. For those cases, which I believe is the majority of cases, there is a massive benefit by doing Agile. 

It's possible that some companies/people don't have enough talent and expertise in the house or don't want to let them HIPPO go away. Therefore they can do proper agile, but don't be mistaken. It's often very possible to break problems into small increments and have benefits but not always. Agile works best with loosely coupling. If you can decouple your business problems and use them independently, there is tremendous value there. 

Waterfall works better with coupling

Such problems like building a boat, it's very waterfall by nature. These are problems or systems where the coupling is so high that either you do it or you don't. There is no middle ground, and there is no adaptation. You won't see proper increments benefits here, so breaking problems in increments is fake. How can you be agile in those cases? When you could make a waterfall discovery / UX / Software Design before the project and experiment and have feedback before you build. Once you decide to build or start building, there is no turning back. Either you get the whole thing done, or there is nothing done. For these cases, you could either be fast or be slow, but at the end of the day, you need to have all or nothing. By nature, we are talking about high coupling which could be manifested by a series of lack and caused-by like:

Business Debt

  1. Lack: Lack of exploring other markets/options
  2. Caused-by: High Tech debt witch killed flexibility over many years(forcing migrations now).

Nature of the problem / Tech Debt

  1. Lack: High Coupling. Lack of Module product/problem proper increments. 
  2. Caused-by: Historical bad Decisions or Natural coupling. 

For that case, the waterfall will be better because agile would be fake anyway. Because making incremental software just for the sake of making incremental software without real benefits is like taking agile as a silver bullet with no drawbacks. I',m not saying Agile is terrible; I' m saying there is a small number of cases where it is better to be waterfall for more crazy as it sounds. When I say waterfall will be better in some cases and it seems complete non-sense might make me think we see Agile as religion and therefore agile is perfect, and there are no drawbacks, no side effects, no issues just good things, it's no true. Agile is excellent, you do it, but we should think because not all problems are the same. Agile, Lean it does not matter; we should be suspicious if something doesn't have issues. Denying could quickly making us bling and definitely would be bad for us in the long term. 


Diego Pacheco

Popular posts from this blog

Kafka Streams with Java 15

Rust and Java Interoperability

HMAC in Java