Lost in Translation - The ‘Waterfall’ Methodology

While it is true that software projects have had more than their share of failed projects, the methodology took the bulk of the blame. Agile, as discussed before, was thus born to correct all that was wrong with Waterfall. But is the methodology to blame for failures, or is its adoption? Let's explore Dr. Winston W Royce paper 'Managing the Development of large software systems'.


No Iterations!

Waterfall, as practiced, is a non-iterative methodology. Which it is not if you look at Dr. Royce's paper. He considered iterations as necessary, without which the implementation, as he said, will be 'risky and invites failure.' He cites at least two examples. He suggests a single loop to address a bug, or a multi-step to solve a performance problem relating to architecture.
 

Phase Dependency (Integration Risk)

Since the technology to monitor and control initiatives available now did not exist back in 1987, Dr. Royce introduced phases to monitor the projects, thereby avoiding surprises. These phases, however, resulted in creating silos. One phase would start only after the previous one had completed e.g., Testing would begin only on completion of the Development. On the contrary, Dr. Royce recommended bringing Development and Testing as close as possible, Testing as the Development gets completed. Continuous integration testing improves timelines and reduces project risk. 
 

Documentation and User Experience

Since there were not many tools for design automation, Dr. Royce emphasized documentation at each stage of the software life cycle. His heavy emphasis was to ensure the practical usability of the software. However, it got caught in the 'on-time', 'on schedule', and 'In scope' triangle. The user's ability to use the software, which was THE driver for documentation, got buried under a pile of cookie-cutter collateral. 
 

Testing

Considering the importance of Testing and its potential to impact project scope, timelines, cost, and usability, Dr. Royce insisted the test coverage should include every path that the software can traverse. It entailed business processes to be the driver for test cases ensuring exhaustive coverage and not limited to the 'Use cases' identified by stakeholders. While adopting, however, stakeholder inputs took precedence in driving test coverage. Accurate Testing of software thus happened not in UAT, but after the software went into production. It resulted in many project failures.
 

Conclusion

Dr. Royce did not name his methodology 'Waterfall.' It got this name at some point while being adopted. However, that name brought a thought process along with it, and anything that deviated was ignored or modified. The methodology suggested by Dr. Royce is a powerful, intuitive way of managing projects. Agile is what Waterfall would look like with the right perspective.
 


About the Author

Sanjay Bhatnagar is a seasoned professional, Chartered Accountant, and certified PMP, with more than 20 years of experience in ensuring success through empowering, engaging, and leading a global team of highly skilled people. He is an expert in Oracle Financials, Costing, Manufacturing, Supply chain, and Treasury, and has worked with small, medium, and large companies, spread across the globe including EMEA, APAC, and North America.

Call 866-531-9587 / Fill out the contact form.