04Predictive and adaptive
Two responses to uncertainty: protecting a baseline or updating a forecast.
If PMBOK and Scrum share an ancestor, is Scrum simply a modernised PMBOK? It is tempting to say so, but the answer is no. The two rest on different assumptions about what can be known at the start of a project.
Parallel lineages
Agile did not grow out of PMBOK. Iterative and incremental development was practised from the 1950s onwards in aerospace and defence programmes. Winston Royce's 1970 paper, often cited as the origin of the waterfall, actually warned against running its sequence in a single pass. The first PMBOK Guide appeared in 1996, Scrum was presented in 1995, and the Agile Manifesto was signed in 2001. The two traditions developed side by side.
Two theories of knowledge
The classic PMBOK lifecycle assumes that enough can be known upfront to plan the work. Deviation from the plan is therefore an error, and control means bringing reality back in line. Scrum assumes that much cannot be known upfront. Deviation is information, and control means updating the plan with what has been learned. Process control theory calls these the defined and the empirical models.
| Dimension | Predictive (classic PMBOK) | Adaptive (Scrum) |
|---|---|---|
| The plan | A baseline to protect | A forecast to update every sprint |
| A deviation | An error to correct | Information to act on |
| Fixed and flexible | Scope fixed; time and cost absorb uncertainty | Time and cost fixed per sprint; scope absorbs uncertainty |
| Requirements | Collected, documented and baselined | Discovered, refined and validated by working software |
| Change | Through integrated change control | Through reordering the Product Backlog |
| Delivery | Usually at the end of a phase | A usable increment at least every sprint |
Table 1 · Two responses to uncertainty. Neither is better in the abstract; each fits a different kind of work.
Requirements show the difference most clearly. In PMBOK, collecting requirements produces documentation and a baseline that change control then protects. In Scrum, a user story is deliberately incomplete, often described as a placeholder for a conversation. It is refined continuously and validated by working software rather than by sign-off. Agile teams do not document requirements less carefully; they treat requirements as hypotheses to test.
PMI absorbed agile
The modernisation ran the other way. PMI published the Agile Practice Guide with the Agile Alliance in 2017. The seventh edition of the PMBOK Guide, in 2021, replaced the process-group structure with principles and performance domains, and described a spectrum of development approaches from predictive to adaptive, with hybrid approaches as a legitimate option. The accurate statement is that PMBOK modernised itself by incorporating agile.
The choice depends on the work
Neither approach dominates everywhere. A bridge, a data-centre migration on a fixed date or a regulatory submission still benefit from predictive planning. Software products with uncertain requirements benefit from adaptive delivery. Many real projects need both. In medical device software, design controls expect traceable, documented requirements, and the workable answer is usually hybrid: adaptive development inside predictive gates. The AAMI TIR45 technical report describes how to combine them.
This is why vocabulary matters. Calling Scrum "optimised PMBOK" alienates agile practitioners. Saying agile "replaces" PMBOK alienates project management offices. Speaking of predictive and adaptive approaches, chosen according to the uncertainty of the work, is accurate and acceptable to both.
Section takeaways
- Scrum is not an optimisation of PMBOK. It rests on an empirical model of knowledge, where deviation is information.
- Predictive planning protects a baseline; adaptive planning updates a forecast. Both are planning.
- PMI has itself adopted the predictive-to-adaptive spectrum. Hybrid approaches are legitimate, and common in regulated industries.