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.

DimensionPredictive (classic PMBOK)Adaptive (Scrum)
The planA baseline to protectA forecast to update every sprint
A deviationAn error to correctInformation to act on
Fixed and flexibleScope fixed; time and cost absorb uncertaintyTime and cost fixed per sprint; scope absorbs uncertainty
RequirementsCollected, documented and baselinedDiscovered, refined and validated by working software
ChangeThrough integrated change controlThrough reordering the Product Backlog
DeliveryUsually at the end of a phaseA 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.