Most if not all of the agile software development processes are based on the assumption that it is hardly possible or not possible at all to predict the real requirements and real workload size at the beginning on the project. The whole idea of agility is to try implementing the most critical stuff, see how it goes, get customer feedback and adjust the close plans.
Such limitation of the upfront planning minimizes the amount of time wasted on never used overplanning and on developing features, that after later consideration happen to be wrongly understood or unnecessary at all. Also the detailed plan non-existence welcomes changes easier. If there are no planning results to modify, there is no temptation to just follow the obsolete plans.
Unfortunately very limited amount of upfront planning also minimizes the forecasting possibilities. Without the longer time estimations it is not possible to commit to multi-million and multi-year contracts. In most of cases the waterfall’s ability to predict the length and costs of the project is anyway an illusion, but nevertheless long time project estimations are required before committing to any non-in-house project.
There are two major ways to overcome the prediction obstacle:
- Build trust with your customer so that he trusted in your ability and commitment to deliver results as soon as possible and as well as possible
- Utilize the agile process’s power not only to adjust to changing requirements, but also to deliver functionality and improved estimations fast. Split the big project into several parts and contract delivery of each of those separately. In fact you don’t even need to tell the customer about the very first phase Ã¢â‚¬â€œ behind the scenes you could run the first spikes during the time that waterfall guys would spend on the initial requirements analysis.