Apr 22, 2022
Agile vs Waterfall
The two ways companies seem to go in terms of project management for engineering. In short Agile is very flexible and iterative which can drive a project in a variety of directions, on the other hand waterfall is linear drive with a heavy focus on planning and a clear end goal.
This is a bit of an opinion piece, but in my young career I have been through both processes and I’ll highlight what I think about them and potential ways to improve on them.
Note: This is specific to software, which has it’s own nuances as it’s a brand new field compared to established fields such as field sciences and etc.
Waterfall is interesting in actual implementation versus the ideal. What I’ve noticed in this setup is that companies what to plan as much possible. It’s easier to say “we got all things figured out” then “we have no fucking clue”. The old corporate (or older ran type corporations) typically appreciate as much predictability in projects, which waterfall provides a framework for. However, things change constantly (especially in technology) and this becomes a massive headache to manage in waterfall. Now on top of the fact a set due date exists and shit just hits the fan.
So what happens in “waterfall” that breaks down as mentioned above? The main issue I’ve noticed is that when no flexibility exists for projects that have a vast amount of possibilities, you end up changing some things and requirements always change. Then with a the same due date you can’t do anything, so you end up with more half done work marked as full done otherwise enjoy the performance reviews (or the manager will enjoy his).
However waterfall strives at one very important aspect that agile struggles with in companies, a single focus. Anytime a project comes through the pipeline and it needs stories created to plan out, at the end the goal generally remains the same to provide that project in the intended way. Since it’s common to say no about significant changes to the project before next release cycle, the end result is generally more complete.
One other point about waterfall, is the final documentation result isn’t amazing that you would expect, but at least documentation exists. One day I will get good at documentation, but I’m one of those developers for the time being.
Alright who doesn’t love some build, test, and deploy. The iterative development model has been popular recently as it handles a lot of nuance in terms of technology changes, requirements changes, and what ends up happening in the real world.
So overall this model is better for development as dates are flexible and changes to the requirements can be thrown in. However, the flexibility and changes can get a bit overwhelming for a single project. One other thing is that work just keeps piling on as more and more things need to be done, and you end up with no real “done” state which can be frustrating. Some places implement code freezes for projects, but even with that things can pile on whether things are being worked on or not.
So is agile the way since it’s new? Not really for everything, plan to approach a project is always nice to have, even if it goes 100% haywire. The reason for this is to keep a singular focus instead of getting torn off into several directions. My suggestion is if the project is newer, stick to agile until we mold the project into a matured system. Afterwards I’d suggest taking a little bit more waterfall early on in a new feature as well oiled machines don’t need so many changes and iterations as it’s refined. Even if a project needs to be re-done the requirements and what doesn’t work should be. The details of what is causing problems should guide the future of the project and could use more structure and planning.
My real opinion, you can’t apply a methodology to work. Everyone is unique in the way work is approached and trying to capture all work in a certain frame. Software projects are like clay, you mold them as much as possible and genuinely screw up a bunch until you get it right. We approach problems in software trying to make developers more efficient, but if we don’t keep an open mind the projects and us suffer.
Thanks for the read.
