2.1 What Agile Is, Why It Is Needed, and Agile in Projects and BAU
Key Takeaways
- Agile is a family of behaviours, frameworks, concepts and techniques for delivering iteratively and incrementally, not a single named method.
- The need for agile comes from uncertainty: when requirements will be discovered rather than specified, a sequential approach commits to the wrong answer early.
- Iterative means repeating cycles that refine the product; incremental means delivering usable slices of it. Agile approaches are normally both.
- Agile applies to business as usual as well as projects — BAU is ongoing, repeatable work with no defined end, whereas a project is temporary and unique.
- A common misconception is that adopting an agile framework alone will deliver benefits; the framework is only the outer layer of the change.
2.1 What Agile Is, Why It Is Needed, and Agile in Projects and BAU
Quick summary: Agile is a family of behaviours, frameworks, concepts and techniques that deliver work iteratively and incrementally with continuous feedback. It exists because a great deal of modern work is uncertain: the requirements are discovered by building, not by specifying. Agile applies to both projects (temporary, unique) and business as usual (ongoing, repeatable).
Defining agile
There is no single thing called "agile". The word covers a family of approaches that share a set of commitments:
- Work is delivered in small, frequent increments rather than one large hand-over.
- Requirements are expected to emerge and change, and change is welcomed rather than resisted.
- Feedback loops are short — the team learns from real users and real working product, quickly.
- Teams are cross-functional and self-managing within agreed boundaries.
- Progress is measured by working product, not by documents completed.
Scrum, Kanban, Lean and Lean Startup are all members of the family, and they differ substantially. Scrum organizes around fixed-length iterations and defined events; Kanban organizes around flow and limiting work in progress; Lean is a broader philosophy focused on eliminating waste; Lean Startup is oriented to validated learning about a product idea. Recognising that these are different tools for different situations — rather than competing brands of the same thing — is part of the Foundation syllabus.
Why agile is needed
The need for agile is fundamentally a response to uncertainty.
A sequential approach makes its largest commitments at the point of least knowledge. You specify everything at the start — when you know the least about the users, the technology and the market — and then spend months executing that specification. If the specification was wrong, the error is not discovered until acceptance testing, by which time correcting it is enormously expensive.
Agile inverts this. It commits to a direction rather than a specification, and it buys information cheaply by delivering something small and looking at what happens. Concretely, the need arises when:
- Requirements are not fully knowable up front. Users cannot describe what they want until they see something.
- The environment changes faster than the project runs. Markets, regulation and competitors move during delivery.
- Feedback is available and valuable. There are real users who can react to a real increment.
- The cost of being wrong late is high. Early detection of a wrong assumption is worth paying for.
Where none of these hold — a well-understood, stable, heavily regulated build with no useful early feedback — a more sequential approach is a legitimate choice. PRINCE2 Agile is explicit that agile is not universally superior.
Iterative and incremental
These two words are frequently used interchangeably. They are not the same thing, and the distinction is examinable.
| Meaning | Analogy | |
|---|---|---|
| Iterative | Repeating cycles that refine and improve the same thing | Sketching a portrait, then progressively refining the whole sketch |
| Incremental | Delivering the product in usable slices, each adding capability | Painting the portrait one finished section at a time |
Most agile approaches are both: each iteration produces an increment that is potentially usable, and later iterations refine what earlier ones produced. The combination is what makes early benefit realization possible — you can release increment one while iterating on increment two.
A common misconception
The syllabus specifically expects you to recognise the misconception that adopting an agile framework alone will deliver the benefits.
Organizations routinely install Scrum events, rename their project managers, buy a tool, and then find nothing improves. The framework is the outermost, most visible layer of agile, and it is also the least consequential without the layers beneath it. Without a genuine change in mindset, values and behaviour, the ceremonies become theatre: stand-ups turn into status reports to a manager, retrospectives produce actions nobody implements, and the backlog becomes a requirements document with a new name.
By contrast, the following are true of agile and are therefore not the misconception: agile is about empowering teams; agile focuses on producing higher-quality products; agile enables teams to minimize waste and reduce delays.
Projects and business as usual
PRINCE2 Agile applies to project work and to business as usual (BAU), and expects you to distinguish them.
| Project | Business as usual | |
|---|---|---|
| Duration | Temporary — a defined start and end | Ongoing, no defined end |
| Output | Unique product, service or result | Repeatable, routine output |
| Purpose | Introduces change | Sustains steady-state operations |
| Team | Cross-functional, assembled for the project | Standing operational team |
| Governance | Project board, business case, stages | Line management, operational budgets |
The four characteristics of a project worth memorising are that it is temporary, unique, introduces change, and is delivered by a cross-functional team. If a question asks which characteristic implies that a project has a start and an end, the answer is temporary.
Agile fits BAU very naturally — a Kanban board managing a stream of support requests is agile without being a project. What BAU lacks is a business case, a defined end, and a project board, so the PRINCE2 governance apparatus is not applied to it. PRINCE2 Agile's guidance on tailoring practices to BAU matters most at the boundary: when a project closes, its product transitions into an operational environment where BAU teams take it on.
Which characteristic of a project implies that projects have a start and an end?
What is a common misconception about agile?
A team delivers a working booking screen in week two, then a working payment screen in week four. Each is usable on its own. Which term describes this?