Waterfall practitioners often think that big design up front reduces risks of failed implementations and in ideal world ideal designs would be approved by ideal users. This however is not the case as business stakeholders have little time, understanding (and sometimes interest) in high level or detailed technical designs. Some organisations address the problem by increasing the ranks of business analysts, tightening the process and improving the process of modelling solutions with BPL or UML.
This however works as no panacea to the problem as it merely disperses the design responsibility amongst higher number of people and shifts the design at higher levels of abstraction. Precious time is being lost in documentation sausage machine, endless meetings and lengthy approval process. It’s very hard to make sure developers remain focused through this process and able to focus on other work. Amount of time wasted in the process is not dissimilar to burning money. This is exactly the reason why agile methods were introduced in the first place. Agile addresses the problem of ambiguity by reducing the number of layers, people and processes that separate the clients or business users from the working software.
Naturally agile assumes that not all of the software is working perfectly and a large proportion of releases are far from perfect, however daily iterations enable improvements in much continuous fashion than they would be feasible using waterfall, simply because there’s more time for finding and fixing all bugs, including the ones that initially were deemed out of scope. The faster the team iterates the easier it is to deliver more bug-fixes towards the deadline. Assuming the same team is prone to leaving same number of bugs in the same code developed in same time, having more time to bounce the product off real users and fix them all is by far better risk mitigation technique than waterfall.
Agile teams usually go through many iterations, trying out more scenarios and conducting more tests than their waterfall counterparts. Development following agile is open to discovering more defects hand in hand with stakeholder buy-in as they go through many beta releases preceding the formal release date. Agile is superior method of reducing risks because it assumes reducing number of defects by shipping software early and spending more time in testing that it would be provided in waterfall. Where waterfall follows “better because of more design” agile delivers “better because of more tests”. It’s a difference between a car that has been designed in a better way to a car that just performs better on a road.