Agile vs. Waterfall Development
Rémy Fannader, an author and founder of Caminao, started a discussion about agile vs. waterfall on LinkedIn. As part of his discussion, Rémy compares the distinction between agile and waterfall as basically a right vs. left brain exercise. While I won’t address the right brain vs. left brain aspect, I have always been interested in the differences—and, yes, even the similarities—between agile and waterfall development methodologies. We have to face the truth that agile was created because of the real and perceived failures of the waterfall methodology in software development.
Waterfall: Where Does it Work?
There are arenas where waterfall works really well. A few come to mind: the fields of manufacturing, medicine, and technology. In the initial stages of manufacturing, one could argue that agile methodologies are used in prototyping products; however, once the product is finalized, manufacturing follows a very rigid process in which it flows from step to step. In medicine, doctors follow protocols that are very rigid and very waterfall—when diagnosing illness and performing surgeries. In technology, waterfall development can be successful when you know the requirements, which are locked down and cannot be modified without good reason. Additionally, in waterfall there is no rigid timeline to abide by. Of course, what I just stated is almost never a reality, although I think perhaps it does happen in some companies.
Agile: Is it a Close Cousin of Waterfall?
Before anyone declares me a heretic and burns me at the stake for asking whether or not agile is a close cousin of waterfall, try to look at the reason I ask the question rather than just the question itself. I think one could argue that agile is just a bunch of little waterfalls together. I think agile practitioners would argue that things can change rapidly in agile while the waterfall methodology doesn’t work well with rapid changes. I think the rapid changes and the reset of the development cycle are possibly just the kick off of another waterfall process. Using Scrum as an example, if you have daily sprints or weekly sprints, you may have had ten, twenty, or one-hundred little waterfall processes kicked off. Ultimately, a requirement has to be agreed to, coding has to be completed, system and unit testing need to be finished, and customer signoff has to be approved. That’s what happens in waterfall and agile.
Now to prove my point: In your sprint, you have something you are working on. The customer wants “A” so you start with “A” and you code it, to which the customer says that he wants a new change called “A1.” After you start coding A1, the customer says that he wants a new change called “A2,” and you agree to code it. After you perform system and unit testing on A2, the customer says that he wants another change called “A3,” and so you develop A3 with the new requirement and perform more system and unit testing. Eventually, the customer says that everything looks good, and you finally get a signoff. What I just explained was a waterfall process with three waterfalls within it.
Conclusion
On a website about agile, I came across the following quote that I feel supports what I am saying:
“Agile methodology means cutting down the big picture into puzzle size bits, fitting them together when the time is right (e.g., design, coding, and testing bits). So, while there are reasons to support both the waterfall and agile methods, however, a closer look clarifies why many software and web design firms make the more appropriate choice of employing agile methodology.”
Are those puzzle size bits just little waterfalls? The unnamed author talks about design (i.e., requirements), coding, and testing in agile methodology and testing. That sounds like waterfall to me. Let the trash talking begin.
