A common differentiator between Waterfall/Traditional software development and Agile is the concept of “predictive” vs. “adaptive.” However, this does not mean that Agile does not provide predictions – nor, conversely, that Waterfall cannot be adaptive – but that Agile and Waterfall are predictive (and adaptive) in fundamentally different ways.
As I have noted many times, a defining characteristic of Waterfall is the amount of time and resources spent up front attempting to provide as accurate a prediction/forecast as possible. Thus, Waterfall conducts extensive analysis up front to determine detailed requirements specifications, which are then broken down into detailed work packages from which a detailed work baseline can be established. This detailed work baseline then provides the framework and foundation for detailed resource estimations, risk identification and analysis, proposed work schedules, and all of the other detailed artifacts associated with Waterfall projects.
However, just like predicting the weather, the accuracy of these detailed estimates has a time-based component relating to both how old (or fresh) the estimates are, and how far into the future they extend. And, just like weather regions, some projects lend themselves to fairly accurate predictability (like deserts and tropical rain forests), and some are very difficult to predict from one day to the next (like Springfield, Missouri).
Needless to say, Waterfall tends to favor projects on the stable side of long-term predictability, while Agile was designed to accommodate projects with very low predictability; namely, “new technology” projects and, more specifically, software development. For these types of projects, the proven method is to combine a short forecast window with the ability to rapidly adapt to changing conditions – hence, Agile’s focus on short-term iteration plans and continuous backlog grooming and release planning.
While predictability is necessary for all projects in order to coordinate resource usage, acceptance testing, release deployments, and other processes needed to manage a modern collaborative organization, overreliance on predictions can have highly negative effects; often culminating in the dreaded “death march” phase of many IT projects, where developers are forced to work long hours to meet milestones and delivery dates that were predicted months (or even years) in advance, and where product owners are often forced to accept reduced quality and functionality to meet these deadlines. Arguably, this is a leading contributor to the low performance record of IT and software development projects.
Agile responds to this by introducing the concept of “reasonable” predictability, and by providing mechanisms for defining what “reasonable” means for each individual project. It also provides mechanisms for satisfying the predictive needs of organizations to define long-term strategic plans and juggle the resource allocations needed to operationalize them; specifically by generalizing long-term forecasts. Thus, after analysis, an Agile project may predict the general need for a team of a certain size and resource requirements for a six month development period, give or take a month or two depending on identified risks. This is usually “reasonable” for most tactical and operational planning. Within that six-month general project window, the project team will then identify the window size for “reasonable” predictability for operationalizing that specific project – usually between 1 and 4 weeks – and that will be the iteration period for the project. Iteration planning will then focus on providing the best possible forecast for the 1-4 weeks of the applicable iteration, while backlog grooming will be used to pencil in and adjust release-level forecasting as domain knowledge and operational conditions change on the ground.
So, Agile projects are still very much “predictive” projects. Where they differ from Waterfall is by providing a process of allowing “rolling wave” estimates to operate within a sliding window of “reasonable” specificity as determined by the needs of each individual project, but also providing “reasonable” generalizability for longer-term planning. Thus, the process can absorb the variability inherent with IT and software development projects, with minimal impact on overall resource planning and the other high-level collaborative needs of modern organizations.
TheAdaptivePM 
Thank you for this post! We are studying system development methodologies at college, and this article sums up the agile approach to estimation and refinement beautifully 🙂
You’re welcome 🙂
Pingback: Agile is still predictive | nickburns2013
Pingback: Forecasts and commitments | TheAdaptivePM
Pingback: The time-value of project predictions | TheAdaptivePM
Instead of predictability I prefer to use the term uncertainty. In my opinion it has more “positive” meaning what is especially important if project rules must be governed by a contract. Additionally the term uncertainty is used in risks analysis.
More about my point you can find in the post:
Of course discussion on the dynamic project scope greatly depends on the context and audience.
I agree that choice of terminology is highly dependent on context, and I can see where using “uncertainty” as opposed to “predictability” might soften things in terms of contract negotiation 🙂
In choosing “predictability,” I wanted to make a more direct reference to the fact that all projects are predictive and, thus, have varying “windows of predictability” based on various criteria. In that context, I think “uncertainty factor” would more directly correlate with “predictability.” Thanks for the input!