Before I finally made it to a more modern company that fully embraced Agile methodologies, I worked for a firm that used the waterfall method exclusively for project planning.
It was a nightmare.
The Background
I was working for a small firm that had become fairly well-established in its industry. We focused on building clinical management and diabetes monitoring software for both clinicians and patients. Our products were making a real difference in the world, so coming to work every day actually felt important.
Unfortunately, we moved too slowly to do anything substantial.
Our flagship product was coded in Turbo Pascal. It was a robust clinical product, but the age of the codebase meant our primary quality assurance tester was stuck on Windows 98 – most of the tools we used hadn’t been maintained beyond that. I was actually hired as part of an initiative to update our product offering and take the desktop-based application online.
Over my time with this company I was able to add several API layers that allowed clinics to communicate with one another. I also engineered a cross-browser, cross-platform, JavaScript-based blood glucose meter download interface to help move us away from an Internet Explorer/Active-X dependency.
But I never did mange to help launch new web-based projects. There’s a very good reason for that, too.
Waterfall Development
The idea of waterfall development is that you start with a plan – a comprehensive plan for building out the project. Unlike agile development, where the team meets frequently and can pivot quickly when new information is uncovered, the waterfall method means you start with a comprehensive spec and, often, work to meet the spec without coordinating with the rest of the team.
At least not that frequently.
Our system started with a client request for a feature. That feature was then fully documented and the ideal implementation roughed out in the planning document. We’d then pass a complete specifications document to an engineer – sometimes they were in-house, sometimes they were outsourced. The engineer would implement the feature, then the new code (and the original spec) were shipped back to the QA tester for verification and acceptance.
It worked, in a way. It was incredibly slow, though, and more complex feature requests (like the rewrite of our Pascal app into something that would work for the web) were lost under a mountain of documentation.
My last project at the company took three months to document. It was a dashboard-style application for tracking and reporting on information like HbA1c, BMI, Cholesterol, and other vital health statistics. We had color coding, interactive reports, automated coordination with clinical management systems. It was a robust application.
It was detailed in an 18-page specifications document that, as I already mentioned, took almost three months to prepare and perfect.
Our requirement before we could even start development was to have a fully-fleshed out specifications document. Unfortunately the overall project and final document were so detailed, that the project was shelved rather than shipped. Our focus on documentation killed any hope of ever moving to development.
How are projects at your company planned out? Do you start with clearly-defined overall goals and discuss momentum frequently to keep development on track while still allowing for agile shifts in day-to-day direction? Or do you start with a rigid specification that squelches creativity and dooms projects to fail if any underlying assumptions prove wrong in the future?