2.4 The Agile Manifesto and Popular Agile Approaches
Key Takeaways
- The Agile Manifesto (2001) states four values, each preferring one thing over another while conceding that there is value in both.
- The four values are: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan.
- The syllabus names four popular agile approaches to recall: Scrum, Kanban, Lean and Lean Startup.
- Scrum is timebox-based with defined events and artifacts; Kanban is flow-based and limits work in progress; Lean eliminates waste; Lean Startup validates product ideas through build-measure-learn.
- PRINCE2 Agile does not mandate any one approach — selecting among them is a tailoring decision driven by project context.
2.4 The Agile Manifesto and Popular Agile Approaches
Quick summary: The Manifesto for Agile Software Development, published in 2001, states four values. Each is a preference, not a prohibition — the closing line is "while there is value in the items on the right, we value the items on the left more." The syllabus then names four approaches you must be able to recall: Scrum, Kanban, Lean and Lean Startup.
The four values of the Agile Manifesto
| We value… | …over… |
|---|---|
| Individuals and interactions | Processes and tools |
| Working software | Comprehensive documentation |
| Customer collaboration | Contract negotiation |
| Responding to change | Following a plan |
The qualifying sentence matters as much as the values themselves. The Manifesto does not say that processes, documentation, contracts and plans are worthless. It says that when the two sides conflict, the left-hand item wins. This is exactly what makes the Manifesto compatible with a governed PRINCE2 project: PRINCE2 Agile still produces documentation, still uses contracts, and still plans — it simply right-sizes each of them and refuses to let them override the left-hand values.
A worked example of each value inside a PRINCE2 Agile project:
- Individuals and interactions. A fifteen-minute workshop with the product owner beats a two-week email chain about a requirement. This is why PRINCE2 Agile leans so heavily on workshops.
- Working software. A stage boundary decision made by looking at a working increment beats one made from a percentage-complete figure.
- Customer collaboration. The senior user and product owner are engaged continuously, not consulted at acceptance.
- Responding to change. Change is expected. It is handled by re-prioritizing the backlog inside a fixed timebox, rather than by a change-control queue.
Beneath the four values sit twelve principles — including delivering working software frequently, welcoming changing requirements even late in development, and reflecting at regular intervals on how to become more effective. Foundation asks you to recall the four values; the twelve principles sit at the "principles" layer of the Agile Onion.
The four approaches the syllabus names
Scrum
A timebox-based framework for delivering complex products. Work is pulled from a product backlog into fixed-length iterations (sprints), each producing a potentially releasable increment.
- Accountabilities: product owner (owns and orders the backlog and maximizes value), scrum master (serves the team and the process), developers (build the increment).
- Events: sprint planning, daily scrum, sprint review, sprint retrospective — all held within the sprint itself.
- Artifacts: product backlog, sprint backlog, increment.
Scrum's strength is cadence and predictability. Its weakness is that fixed-length sprints suit work that can be planned a sprint ahead; they suit unpredictable interrupt-driven work poorly.
Kanban
A flow-based method that manages a continuous stream of work rather than iterating in fixed batches. Its core practices are to visualize the work, limit work in progress (WIP), and manage flow.
- No prescribed roles, events or iteration length.
- Limiting WIP is the central mechanism: it forces finishing over starting, exposes bottlenecks, and shortens lead time.
- Progress is measured with flow metrics — lead time, cycle time, throughput, cumulative flow.
Kanban suits support, operations and any stream where work arrives unpredictably, and it is the least disruptive way to introduce agile into an existing process because it starts with the process you already have.
Lean
A broader philosophy, originating in manufacturing, focused on maximizing value and eliminating waste. Anything that does not add value to the customer is waste: partially done work, hand-offs, waiting, defects, unnecessary features, task-switching.
Lean thinking underlies both Kanban's flow orientation and agile's suspicion of large batches. It contributes the vocabulary of pull, flow and continuous improvement.
Lean Startup
An approach to validated learning about a product idea under extreme uncertainty. Its engine is the build-measure-learn loop: build the smallest thing that tests an assumption, measure real behaviour, learn whether the assumption held, then persevere or pivot.
Its signature artifact is the minimum viable product (MVP) — a version of the product with just enough features to generate the feedback you need. Lean Startup is the right tool when the biggest risk is "will anyone want this?" rather than "can we build it?"
Telling them apart
| Approach | Organizing idea | Fixed iterations? | Signature concept |
|---|---|---|---|
| Scrum | Timeboxed delivery of increments | Yes | Sprint, product backlog, three accountabilities |
| Kanban | Continuous flow | No | Visualize work, limit WIP, manage flow |
| Lean | Eliminate waste, maximize value | N/A — a philosophy | Waste, pull, flow, continuous improvement |
| Lean Startup | Validated learning under uncertainty | No | Build-measure-learn, MVP, pivot or persevere |
Other approaches you may meet in practice — Extreme Programming, DSDM, SAFe, LeSS, Scrum@Scale — are compatible with PRINCE2 Agile but are not the four the Foundation syllabus asks you to recall.
The tailoring point
PRINCE2 Agile deliberately does not nominate a winner. Selecting the approach is a tailoring decision, taken in the light of the project's context: the nature of the work, the maturity of the teams, the stability of requirements, and the regulatory environment. A single project may legitimately run Scrum in one team and Kanban in another, provided both feed the same release map and report against the same tolerances.
Which pair correctly states one of the four values of the Agile Manifesto?
Which agile approach is organized around visualizing work, limiting work in progress and managing flow, with no prescribed iteration length?
A team is highly uncertain whether customers want a proposed service at all. Which approach is most directly designed for that problem?