Waterfall vs. Agile Models in Technical Documentation
© Ugur Akinci
As a technical writer I’ve worked in both Waterfall and Agile shops. The differences between these two methodologies were pronounced and obvious.
To understand the Waterfall model imagine a river going down a mountain through a series of waterfalls. The water stands for your product, the software product. The product goes through each stage of development only once, just like the water passes through various points on its way to the sea for only once.
The various points correspond to the different phases of software development like Architectural Design of the product, the Market Specs, functional specs, actual development (coding), engineering unit testing (ET), regression or system testing , Quality Assurance (QA) testing, and release.
Technical documentation weaves through these phases and tries to catch up with the product development so that when the product is ready for release, all the necessary technical documentation would be ready too. That’s the ideal situation.
This means that, in the Waterfall Model, a technical writer constantly asks SMEs what they are doing and tries to compile all the information she can about all aspects and features of the product, making multiple rounds and preparing multiple drafts until she runs out of time and cannot do any more drafts. At that point the documentation would be considered “complete.”
Since the product is not considered complete until ALL these phases are finished, in the Waterfall Model it takes a long time to develop and finish a product, typically somewhere between a year to two years. For about 18 months an organization invests a lot of time and money to develop something for which (in this fast moving market of ours) the demand might not be there any more. That’s the first possibility.
The second possibility, after all that time and effort the product might not work as planned. Or thirdly, a customer may say he changed his mind, or the needs have changed and even though the product works just find it’s now obsolete or redundant.
So in such a situation what happens to all that documentation and months and years of development? They all go to the waste basket. I have exaggerated and dramatized it a little bit but you can see the kind of high potential risk Waterfall Model presents in a fast moving market.
To minimize or eliminate such a risk, the Agile Model proposes NOT to work on the whole product but on only a small part of it to create what is called a “Minimum Viable Product (MVP)” and do it in only 2 or 3 weeks. In this model, if the worst happens and everything goes to waste, the company loses only 2 to 3 weeks worth of labor instead of 18 or 24 months.
MVP is something that can potentially be delivered to the customer and it would work. It’s a total independent product unit that is developed regardless of what happens to other parts of the product. In this model, the technical writer documents only the MVP or a small work unit instead of the whole product.
Agile teams work in 2 to 3 week sprints under the guidance of a Scrum Master. As a part of the sprint, technical writer also works in short but intense documentation runs.
This topic is too deep to be covered exhaustively in this short answer but let me summarize it by saying that the role of the technical writer is very different in these two models. You have to be ready to shift gears and adapt yourself to the comprehensive and slow documentation cycle of the Waterfall Model or the intense and fast documentation cycle of the Agile Model which requires a higher level of mental alertness and increased commitment to research and details.
