The best criticism of PRINCE2 Agile is a decade old and it has never been properly answered.
In 2015, shortly after passing the Practitioner exam, Luc van Veggel wrote in a comment on Henny Portman’s blog that instead of best practice, “it’s a monster—full PRINCE2 use in Agile projects, like plowing a garden with a bulldozer.” He had wanted an agile PRINCE2 and found the reverse, and called the whole thing “a significant mistake by Axelos.”
Larry Cooper of BSSNexus Global made the same point more diplomatically in InfoQ around the same time: “Blending Agile with PRINCE2 processes will likely be a challenge for both communities to fully embrace,” and many “may see it as adding a set of heavy processes to Agile.”
I should be honest about what a decade has done to that debate. There is no substantial named critique of PRINCE2 Agile after about 2020, and none at all of Version 2. The critical literature is concentrated in 2015 and 2016, around the original launch. That is not evidence the criticism was answered. It is evidence the argument moved on, and quoting decade-old scepticism as current opinion would be dishonest.
But the bulldozer line survives because it describes something real, and anyone adopting the method should understand exactly what it is attacking — and what it is not.
The criticism is against an untailored implementation
PRINCE2’s seventh principle is tailor to suit the project. It has always been there and it has always been the least applied part of the method.
The bulldozer failure looks like this. An organisation adopts PRINCE2 Agile. Somebody produces a set of templates — a project initiation document, a business case, a risk register, a quality register, a stage plan, a highlight report, a checkpoint report, an exception report, a lessons log, an issue register, product descriptions. All of them are correct. All of them are required “for compliance.” A two-month piece of work now carries the documentation load of a two-year programme.
Nobody intended that. It happens because tailoring requires somebody to take responsibility for removing things, and removing things is career risk. Producing the full set is defensible; producing three-quarters of it requires a person to have made a judgement they may later have to defend.
So the first thing to say about adopting PRINCE2 Agile is that tailoring must be an explicit, authorised act, performed by a named person, recorded in writing. Not an implicit permission. A decision, in the project initiation documentation, that says: these products we will produce, these we will not, and here is why.
If your method has no tailoring statement, you have the bulldozer, whatever the training said.
What the defenders get right
Two defences hold up.
Scope. PRINCE2 Agile governs project management, not delivery. It is not competing with Scrum for control of how a team builds software. Keith Richards, the lead author of the original guidance, described PRINCE2 and agile as “complementary, just like salt and pepper.” The Agilometer exists precisely so that the governance wrapper can be calibrated to how much agility the environment supports.
And there is a genuine need. Jay Gao of Knowledge Train put the commercial reality plainly in December 2025: “Organisations want the predictability of PRINCE2 with the responsiveness of agile.” Jamie Lynn Cooke’s definition is the most precise I have found — PRINCE2 Agile is “an adaptive governance method for project delivery that combines senior management’s ongoing need for business-value confirmation and due diligence with the empowerment and flexibility that the project team needs.”
That need is not manufactured. Every organisation I work with that has adopted agile delivery at scale has run into the same wall: the delivery teams are genuinely more effective, and the board has genuinely lost its line of sight. Somebody has to solve that, and refusing to on ideological grounds helps nobody.
The method-blaming trap
There is a piece of writing I recommend to anyone in this argument.
Willem-Jan Ageling published “PRINCE2 didn’t work for us so we went back to Scrum” in January 2020, containing lines like “It was a good experiment. Now we know that PRINCE2 is nothing for us” and “We are in a REAL business and we want to build our products fast.”
He also published a deliberate companion piece: “Scrum didn’t work for us so we went back to PRINCE2.”
The pair is a rhetorical device about method-blaming, and citing only one of them — which is what most people do — misrepresents him entirely. The point is that organisations attribute to methods what belongs to their own capability, and they do it in whichever direction is currently fashionable.
I have seen both migrations. Neither one fixed anything on its own. What fixed things, when anything did, was a small number of unglamorous changes: somebody empowered to decide, a real definition of done, honest estimating, and a board willing to stop work.
When the method met reality: two short cases
Lidl. From 2011, Lidl worked with SAP to replace its legacy merchandise management system with a bespoke build covering supplier-to-customer process chains across roughly 10,000 stores and 140-plus logistics hubs, with over 100 IT specialists. It was deployed in Austria from May 2015, plus Northern Ireland and the USA. In July 2018 it was terminated, and Lidl reverted to developing its legacy system in-house.
The internal memo said the strategic goals as originally defined “could not be achieved without the retailer having to spend more than it wanted.”
A figure of around €500 million circulates widely. I want to be careful with it: Lidl declined to disclose figures, and the €500 million is an estimate attributed to observers, not a company-reported number. There is a widely repeated story about inventory being valued at purchase price rather than retail price, forcing modification of standard SAP; I could not verify that mechanism in a primary source, and I would not print it as fact. What is documented is the general pattern — a heavily customised bespoke build over seven years that could not be economically extended.
Seven years is the number that matters. Seven years is long enough for the business that commissioned the system to stop being the business that needs it.
Revlon. A big-bang SAP cutover at Revlon’s largest manufacturing facility in February 2018 produced warehouse and production integration failures, inadequate user training, and an order backlog that set operations back roughly two months. $64 million of net sales were not shipped; $53.6 million of incremental remediation charges followed.
What makes Revlon distinctive is that the failure escalated from a delivery problem into a control environment finding, disclosed by the company under securities law. In its 2018 Form 10-K, Revlon disclosed a material weakness in internal control over financial reporting, stating it “did not perform an effective continuous risk assessment process” and “did not maintain a sufficient number of knowledgeable, trained personnel.”
Read that second phrase as a project management finding, because that is what it is. Not enough people who knew what they were doing. It is the same finding Grant Thornton reached at Birmingham, where the digital directorate could not act as an “intelligent customer,” and the same finding the Auditor General reached at Phoenix.
No method compensates for that. If your organisation does not have people who understand the system being implemented well enough to challenge the integrator, the framework you adopt is close to irrelevant.
A practical adoption sequence
If you are actually going to do this, here is the order I would work in.
1. Run the Agilometer before you choose anything. Six sliders, scored anonymously, by people from different parts of the delivery chain. Design around the lowest score. If the environment cannot absorb agility, tailoring towards more structure is a legitimate answer, not a defeat.
2. Write the tailoring statement first, not last. Which management products will you produce, at what frequency, for what size of project? Put a threshold on it — for example, work under a defined size uses a one-page project brief and a single stage. Have the project board approve the tailoring, so it is authorised rather than improvised.
3. Name the eleven roles and your combinations. Project Executive, Chief Product Owner, Senior Supplier, Project Assurance, Agile Coach, Project Manager, Project Support, Product Owner, Team Coach, Developer, Tester. Write who holds each. Then look specifically for combinations where the same person both does work and assures it — that is where governance quietly disappears.
4. Fix the definition of done before the first increment. Product descriptions with quality criteria and quality method. The Hertz litigation is a two-hundred-page argument that could have been prevented by a paragraph.
5. Certify narrowly. Foundation for everyone who needs the vocabulary; Practitioner only for people who will run projects. The usual ratio is about four to one and organisations routinely over-buy. Remember that PRINCE2 Agile Practitioner Version 2 no longer accepts PMP, CAPM, IPMA or PRINCE2 7 as prerequisites — only PRINCE2 Agile credentials — so a PMP holder must now start at Foundation. And accredited training is not mandatory at any level, unlike ITIL’s advanced modules, which changes the cost calculation considerably.
6. Measure three things and nothing else, for the first year. Forecast accuracy at each stage boundary. Number of projects stopped by a board decision. Time from a problem first being written down to it reaching a decision-making forum. Those three will tell you whether governance is functioning. Nothing on a burndown chart will.
7. Diarise the deadlines. PRINCE2 Agile Version 1 exams end on 31 December 2026 and vouchers stopped being sold on 30 June 2026. PRINCE2 6th edition is fully retired. There is no published retirement date for PRINCE2 7 or PRINCE2 Agile Version 2, and no announced roadmap beyond them.
What I actually think
PRINCE2 Agile is a reasonable answer to a real problem, and it is not a transformation.
Version 2’s rebuild onto PRINCE2 7 makes it internally coherent for the first time — the previous version was aligned to an edition that had been superseded for nearly two years. The Agilometer is a genuinely good instrument that almost nobody uses. The eleven roles force useful conversations about accountability. And there is no independent evidence that adopting it improves outcomes, because no such study exists, and I would rather say that than sell you a percentage.
The bulldozer criticism remains fair against any implementation that skips tailoring, and most implementations skip tailoring, because tailoring requires somebody to take responsibility for leaving things out.
So if you adopt one thing from this article rather than the whole method, adopt that: write down what you are not going to do, and put a name against the decision.
That is worth more than the certificate. It is also, in my experience, considerably harder.
A note on who is telling you this
I make my living from training and consulting on these methods, and I hold the PRINCE2 Agile Expert designation. That is a conflict of interest, and I would rather name it than have you discover it at the end.
What it means in practice is that you should apply more scepticism to my enthusiasm than to my criticism. When I tell you the Agilometer is under-used, note that I also sell the course that teaches it. When I tell you there is no independent evidence that PRINCE2 Agile improves outcomes, note that this is a statement against my own commercial interest, which is generally a reasonable signal that it is worth taking seriously.
The test I would apply to anyone selling you a method — including me — is simple. Ask what the method cannot do. If the answer is a pause followed by a benefit, the person is selling. If the answer comes quickly and specifically, they have probably implemented one.
Sources
- Henny Portman, PRINCE2 Agile (4 September 2015), including Luc van Veggel’s comment — hennyportman.wordpress.com
- Savita Pahuja, PRINCE2 Agile — Larry Cooper quotes, InfoQ (8 June 2015) — infoq.com
- Panagiotis Fiampolis, Making sense of PRINCE2 Agile, PM World Journal (May 2015) — Keith Richards “salt and pepper” quote
- Willem-Jan Ageling, PRINCE2 didn’t work for us so we went back to Scrum (19 January 2020) and its companion piece — ageling.substack.com
- Jamie Lynn Cooke, The PRINCE2 Agile Practical Implementation Guide, 2nd edn, IT Governance Publishing (2021)
- Knowledge Train press release, 17 December 2025 (Jay Gao quotes)
- PeopleCert, PRINCE2 Agile Foundation (Version 2) and Practitioner (Version 2) syllabi and certification pages; Certification retirements update
- Computerwoche and contemporaneous reporting on Lidl’s eLWIS termination (July 2018); the €500m figure is a third-party estimate, not company-reported
- Revlon, Inc., Form 10-K for 2018 (material weakness disclosure)
- Grant Thornton on Birmingham City Council; Office of the Auditor General of Canada on the Phoenix pay system