Part 1: The false security of Waterfall Projects

Since this is supposed to be an introduction to Agile methods for more “old fashioned” or traditionally minded companies, we need to start from the beginning.  Therefore, let’s first look at benefits and flaws in the most commonly used project methodology for this kind of companies; the Waterfall Model.

Please note that there certainly are projects that benefits from a Waterfall modeled project approach, such as large infrastructure investments etc. It is also not totally uncommon to mix in some components from Waterfall into Agile run projects/initiatives, but this often results in more overhead.

Short Summary: Benefits of Waterfall projects: Control, Structure, Outcome is clear Drawbacks of Waterfall projects: Workload for stakeholders, Inflexibility, Outcome often does not satisfy expectations

• Everyone gets up to speed quickly:
  • Since technical documentation is a necessary part of the initial requirements phase, this means that everyone understands the objectives. New developers can get up to speed quickly – even during the maintenance phase.
    • However, this requires a meticulous documentation that takes all aspects into account from the beginning.
• Timelines are kept:
  • The phased development cycle enforces discipline. Each step has a clearly defined starting point and conclusion, which makes progress easy to monitor. This helps reduce any project “slippage” from agreed timescales.
    • This is true as long as there are no changes and that the initial documentation and requirement settings are fixed and clear
• No financial surprises:
  • Costs can be estimated with a fairly high degree of accuracy once the requirements have been defined.
    • This is dependent on the previous points. If we have changes or we need to adapt the project, costs will increase as stated in the list above.
• Testing is made easy:
  • Test scenarios are already detailed in the functional specification of the requirements phase, which makes the testing process easier and more transparent.
    • This is true, but we have the same situation in an Agile run project, where we have acceptance criteria to be tested after each sprint. Hence smaller pieces to test and thereby it is easier to modify or change the delivery if something went wrong.
• The outcome is crystal clear:
  • Even before the software development starts, the design is hammered out in detail which makes the needs and the outcome clear to everyone.
    • This is true and can also be a problem. In a changing world with changing priorities we will get what we asked for initially. But is it exactly what we want to have once the project is delivered?
• Deal with issues in the design:
  • Potential development issues can be researched and tackled in the design stage – and alternative solutions planned – before any programming takes place.
    • This is true, but again; it requires a fixed world with no of very marginal changes

As we can see, the benefits of the structured way of running Waterfall Projects, highly depend on documentation, very clear and fixed requirements and no changing priorities or needs.

The appeal of the Waterfall Model, which is that it gives control, clear outcome and financially stable projects, is thereby depending on a very structured approach where usually 1/3 to 1/2 of the time must be spent on documentation before even one line of code has been written. And, in the end, the result is quite often disappointing to the end user. This is because the waterfall projects usually focuses on the WHAT instead of the HOW. 

More about this in Part 2: How to think when developing software or implementing an Off-The-Shelf system.