Waterfall vs. Agile

One of the bigger debates in the last few years in project management circles is which development process is better, Waterfall or Agile.

First, some definitions are required.  The Waterfall methodology is a stage gate process where a project is broken down and subsequent work packages are performed after the completion of the previous work package.  This can be seen as a linear process, like building a house.  First the foundation is poured, then the walls are erected, then the roof.

The Agile methodology is an iterative process where finished pieces are constructed, with the possibility of refining or completely changing the original product in subsequent iterations.  One of the core concepts of Agile is to make your mistakes early.  An example of this would be like making pasta sauce from scratch.  You might add salt in the beginning but if you find the sauce to be too salty, you could add more tomato paste and water.  You could also add spices later, to taste.

The debate is which process works better.  The answer is both and neither.  Waterfall is a good process for projects where changes are costly, such as in manufacturing.  When designing parts that require tooling, it could be very expensive to try to iterate.  The old adage of “measure twice, cut once” is still a good rule of thumb for most manufacturing type projects.  Tooling can also be a very long lead item, depending on complexity, so even if non-recurring engineering (the one-time cost to research, develop, design and test a new product)  is not a significant factor, the lost revenue of a delayed product launch would definitely have an impact to the business.

Agile is a better process for software development projects, particularly web solutions.  With Agile development, the project can be completed in iterations that can actually go out into the world for both user testing and to drive business value.  Change is far less costly and is really measured in opportunity cost.  Since Agile development is centered around a forced prioritized “product backlog” the higher prioritized features are done first.  If done properly by the product owners, this should mean that the greatest value (i.e., revenue generating) features come first.

The project development methodology should be tailored to the goals and structure of the individual business.  Even a company that produces pure software projects may want to maintain some aspects of waterfall as a way limit the cost of change.  And hardware companies may want to use some aspects of Agile to make course corrections earlier rather than later in development.

What method is used in your company?  Can you see how aspects of the other methodology could be useful at your company?  Has anyone had the experience of transitioning from Waterfall to Agile?

4 thoughts on “Waterfall vs. Agile

  1. My company uses Agile development in our software design to a fault. Many times, the SDLC process goes beyond agile and results in a code and fix environment to the extreme. Waterfall would be a better solution in some ways as it would force a slower, more methodical pace to ensure that things are being done properly; we have coded so fast for so long, we have lost the ability to relate back to the proper way to do it. A change in processes might rekindle the desire to properly execute tasks.

    Long term, I do feel that Agile is the best way to go for most software developers. Closer to real time feedback is needed before final steps are completed to ensure that needs and requirements are being met.

  2. You bring up a very interesting topic and something that is often discussed in my company. It was until about a year ago that our eCommerce department used Waterfall development process. Many people brought up issues with Waterfall, that it was costly and not efficient to meet the demand. It was often discussed that to bring things faster to the market and be able to make changes on the fly more cost efficiently, Agile was much better. We are now about one year into Agile process and debate is still taking place. In my conversation with one of the Project Managers, he brought up an interesting point. While we claim to be using Agile development process, he said that the teams are mixing Agile and Waterfall which is creating bigger problems. It is critical for the leadership to pick the process and stick to it. In our line of business, Agile seems to be better way and sticking to this process is mandatory for it to succeed. As with any process, once it is established, it is important to follow it in order to understand its value… mixing processes creates more confusion and inability to measure their effectiveness.

  3. Very clear, articulate and written post. I am impressed by how you were able to condense these difficult topics into points that I could understand and relate to. Thank you for making easy for me to grasp and remember! I work in manufacturing and I know full well that every project manager has a different opinion on how to handle projects, whether it be agile or waterfall methods. I have seen the benefit of both, but the folly of both. Most of the time in the waterfall method I get a new piece of equipment or software that can not be modified for my application as it is an “out of the box application” or made specifically to meet the requirements of a regulatory agency both fails to incoroporate the human aspect of running the machine. For example we got a new piece of equipment that would perform clean in place operations on a large 3000 Liter tank. However there were no manways on the tank for manual cleaning. I was upset and confused that this waterfall project did not consider that if the CIP machine failed that manaully cleaning would need to be performed by having a person enter the tank. Either way, really enjoyed the post and I think overall an agile method with a diverisfied user group to make all the mistakes upfront like stated in your post.

  4. We actually use a form of Agile called 4D. 4D is comprised of four phases: Discover, Design, Develop and Deliver. When used correctly it can be very effective but when not followed correctly can cause problems. The primary issue we encounter is that development is expected to start during the same time as Design, which in theory can work well but when design changes dramatically but the timeline does not it causes major problems.

    I’ve actually seen where stakeholders have used the 4D process as an excuse for lack of scope and definition of the project, which is not the point of using 4D or agile. I think Agile can work very well for web development but it still needs to come with requirements and accountability. I’ve found that stakeholders will often refuse or delay delivering requirements in attempts to skirt being held accountable at delivery when they do not foresee requests from the business. It’s an attempt to shift the blame from their lack of requirements to the developers not being agile and lean.

    I would like to see us use a more hybrid approach and build back in waterfall techniques in order to build trust between teams.

Leave a Reply

Your email address will not be published. Required fields are marked *