The Agile Development Waterfall

These days, there is a lot of criticism of the “waterfall” model of development. I believe that is because it is used as a blanket term that actually has three important subcomponents. In a classic waterfall project, the duration of the project is however long it takes with the resources provided to produce the software which meets all of the requirements. There are set process stages that each work item goes through such as requirements gathering, requirements specification, design, development, integration, etc. Lastly, there is the characteristic that all of the work items go through the process stages in lock step.

I submit that all software development projects share an essential part of the “waterfall” model: the steps of the waterfall itself. This is out of necessity. When was the last time you saw code spontaneously pop into existence without being written, or code being written without any goal in mind, even if it was as vague as “make it better?”

All changes to software go through a waterfall of stages. Even if it is a fuzzy idea, change starts with a concept for what needs to be done. From this concept comes a plan. The plan may exist only as a flash of insight in the mind of the developer and they may not even be conscious of it, but there is always a plan. From the plan comes the code. Lastly, the proof of the original concept comes from trying the result. Thus, even in the least rigorous of environments, working on a single issue, there is at least a 6 step waterfall.

All of the stages described may be intermingled, have no clear start or finish, and be repeated multiple times, but they are there. Another way to describe them would be: need, requirements, specification, design, development, test.

The major differences between the classic waterfall model of development and other models of development come in the number and duration of iterations, number of steps in the waterfall, degree of detail in the steps, and the degree of synchronicity between the steps and between the work items.

For instance, the classic waterfall has a single iteration where the duration of the project is however long it takes with the resources provided to produce the software which meets all of the requirements, there is a very high degree of detail including verbose documentation every step of the way, and all of the work items progress together from one step to the next.

In the Agile model, there are frequent short iterations which consist of self-contained projects representing the highest value work that can be done during a single iteration, there is a minimum of detail and documentation, and the work items may or may not progress together from one step to the next, but those steps are still there.

I suggest that the value of the waterfall model, when applied to a single work item, is in producing a well defined series of steps which when followed is known to detect and filter out problems. For any particular development team, those steps may vary a great deal, but by refining the steps and applying them consistently, you have a higher likelihood of producing consistent results.

Next: Sustainable Pace: Supply vs. Demand