The manifesto that named the movement is four sentences long. It values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan, and it says explicitly that the things on the right have value too. Everything else, the frameworks, the roles, the boards and the certifications, is one group's answer to how to live by those four sentences, and none of it is the thing itself. That matters because the frameworks are what gets sold and taught, and it is possible to adopt every part of one while inverting the values it was written to serve.
| Aspect | Predictive delivery | Agile delivery |
|---|---|---|
| What is fixed | Scope; time and cost flex to deliver it | Time and cost; scope flexes to fit them |
| When value arrives | At the end, all at once | Each iteration, incrementally |
| How change is handled | Through a control process against a baseline | By reordering the remaining work at each iteration |
| What proves progress | Milestones and earned value | Working product shown to users |
| Where it fits | Well-understood work, hard external constraints, regulated deliverables | Uncertain requirements, fast feedback available, software |
| Where it fails | Requirements that were guessed and baselined anyway | Programmes with hard dates that pretend not to have them |
The question that decides which to use is how much the organisation knows about what it wants. When the requirements are genuinely understood and the constraints are external and hard, a building, a regulatory filing, a hardware launch, planning the whole thing and controlling changes to the plan is the right discipline. When the requirements are a hypothesis about what users will value, and the only way to test the hypothesis is to build something and show it to them, iterating is the right discipline. Most real work has both kinds inside it, which is why the hybrid approaches the certification bodies now examine are not a compromise but a description of practice. PMI's professional exam now assumes most items are adaptive or hybrid; the Scrum bodies certify the framework itself; PRINCE2 has an agile variant. The vocabulary is shared; the values are the test.
The test that matters
Not which events the team holds, but how many weeks pass between a user seeing something real and the plan changing because of it. Three weeks is agile. Nine months with a daily stand-up is not.
