PRINCE2 Agile Foundation common mistakes
PRINCE2 Agile Foundation · Understand the traps and how to avoid them.
When asked what can be tailored to suit an agile delivery, the candidate lists the seven PRINCE2 principles alongside the themes and processes as tailorable.
Agile's "tailor to context" language and the manual's heavy emphasis on tailoring lead candidates to assume everything in PRINCE2 is adjustable; the principles are less frequently examined than the themes, so their mandatory status is under-rehearsed.
What to do instead
Learn the split explicitly: the seven principles are mandatory and never tailored, only the themes and processes are tailored (informed by the Agilometer). Practise answering with the sentence "principles are applied, themes and processes are tailored".
Describes the Agilometer as a go/no-go test that produces a score determining whether agile can be used, and treats it as completed once at the start of the project.
It looks like a checklist/assessment form, and candidates conflate "assessing suitability" with a decision gate; the emphasis on six sliders is easily reduced to a single score in memory.
What to do instead
State that it has six sliders (flexibility on what is delivered, level of collaboration, ease of communication, ability to work iteratively and deliver incrementally, advantage of using agile, acceptance of agile) used to guide tailoring and risk response, and that it is revisited as the project progresses rather than being a pass/fail verdict.
Answers a question on prioritisation by saying scope is fixed and time and cost flex, or by saying everything must be fixed.
Traditional plan-driven habits plus the phrase "embrace change" push candidates towards fixing scope and flexing dates, which is the reverse of what PRINCE2 Agile advises within a timebox.
What to do instead
Memorise the "fix and flex" rule: within a timebox, time and cost are fixed and scope is what flexes, guided by prioritisation (for example MoSCoW) and tolerances set by the project board.
Equates PRINCE2 roles with Scrum roles one-for-one, for example stating the Product Owner replaces the Senior User or that the Project Manager becomes the Scrum Master.
Both worlds use product- and team-facing roles with similar-sounding names, and candidates look for a tidy mapping instead of learning which accountabilities stay at project level and which sit in the delivery team.
What to do instead
Learn the two levels: the project board (Executive, Senior User, Senior Supplier) keeps overall accountability and the business case; product ownership and team facilitation are delivery-side roles that can be combined with PRINCE2 roles, but combining roles does not remove the accountabilities.
Defines Kanban as "Scrum without sprints" and describes it in terms of sprints, Scrum roles and a backlog.
Kanban is usually encountered as a light overlay on an existing Scrum team, so the distinctive flow-based practices are never separated out in the candidate's mind.
What to do instead
Learn Kanban as a flow-based approach with its own practices (visualise the workflow, limit work in progress, manage flow, make policies explicit, use feedback loops, improve collaboratively) and be ready to contrast it with the timeboxed, role-defined, inspect-and-adapt structure of Scrum.
Reverses or misorders the Lean Startup loop, describing an MVP as a full first release that is measured after launch, or saying the cycle runs learn-measure-build.
The vocabulary (minimum viable product, pivot) is familiar from general reading, but the underlying purpose - validated learning - is not, so the sequence gets scrambled.
What to do instead
Anchor on build–measure–learn: the MVP is the smallest thing that generates validated learning, and the outcome is a decision to persevere or pivot. Answer questions by tracing the loop rather than by defining the terms.
Claims that adopting an agile delivery approach removes or renames PRINCE2 processes, for example that Starting up a Project disappears or that Managing Product Delivery is replaced by the sprint.
Agile ceremonies dominate the candidate's mental model, so the PRINCE2 process names feel like legacy overhead; candidates also assume "agile" means fewer controls rather than differently-shaped ones.
What to do instead
Learn that all seven processes remain and are tailored: Managing Product Delivery is where the agile team's timeboxed work is authorised and accepted (typically via work packages), and stage boundaries, project initiation and project closure still occur with agile-appropriate products.
Treats PRINCE2 Agile as licensing "no documentation", dropping product descriptions and quality criteria on the grounds that agile values working software over documentation.
The agile manifesto wording is remembered as a rule rather than a value statement, and candidates underestimate how central the focus on products and the quality theme remain.
What to do instead
Learn that PRINCE2 Agile retains the focus-on-products principle and product-based planning, using lightweight product descriptions, acceptance criteria and a definition of done; documentation is sized to need ("enough"), not eliminated.
Mixes up the structural elements of PRINCE2 Agile, for example listing the Agilometer as a theme or naming flexibility and rich communication as principles.
Three separate lists (seven principles, seven themes, five focus areas) are learned in the same study session and bleed into each other under exam pressure.
What to do instead
Build a three-column recall sheet and drill it until automatic: principles (continued business justification, learn from experience, defined roles, manage by stages, manage by exception, focus on products, tailor to the environment); themes (business case, organisation, quality, plans, risk, change, progress); focus areas (Agilometer, requirements, rich communication, frequent releases, flexibility).
Classifies an uncertain, requirements-emerging project as "complicated" in Cynefin and prescribes expert analysis and best practice for it, or files straightforward work under "complex".
Complex and complicated sound interchangeable, and candidates learn the domains as labels rather than as cues for which response (sense-analyse-respond versus probe-sense-respond) is appropriate.
What to do instead
Learn each domain with its decision model: simple/obvious (sense-categorise-respond, best practice), complicated (sense-analyse-respond, good practice and expert analysis), complex (probe-sense-respond, emergent practice - where agile fits best), chaotic (act-sense-respond). Judge by the nature of the problem, not by project size.