There’s a lot of confusion between PRINCE2 and Agile methods, and indeed debate (PRINCE2 vs Agile) about which should be used on projects. In fact, both can and are being used increasingly on projects – often together.In 2015, AXELOS, the owners of PRINCE2 launched PRINCE2 Agile. PRINCE2 Agile is an attempt to get the best of both worlds – the structure and governance of PRINCE2, combined with the flexibility of Agile.This article compares PRINCE2 and Agile methods and approaches and explains how PRINCE2 Agile can bridge the gap between the two.
PRINCE2 vs Agile
PRINCE2 is the world's most widely used project management methodology. PRINCE2 qualifications are a standard feature of project management job specifications in the UK and have grown in popularity since PRINCE2 was launched in 1996.
Currently, over 150,000 PRINCE2 exams are sat somewhere in the world every year.
‘Agile’ is an umbrella term used to refer to numerous product delivery methods, frameworks and techniques used by development teams.
Agile approaches emerged from the software industry in the 1990’s, to try to overcome many of the problems which had beset traditional software projects. They were often delivered late, over budget, and with low quality.
Who is PRINCE2 for?
PRINCE2 is a customer-focused project management methodology. It offers a set of principles, themes and processes to enable an organisation’s key managers to justify a project. It helps them understand “why should we do it (the project)?” and “are the benefits worth the costs and risks of doing the project?”. It also focuses on how to manage a project effectively to ensure it still is a worthwhile investment in a changing business environment.
PRINCE2 was developed by the UK government in 1996 as a generic project management methodology.
Focus of PRINCE2
PRINCE2 is based upon a set of 7 principles which guide all aspects of the method.
Since it is a project management methodology, it describes the roles and responsibilities of all members of the project management team. This includes higher levels such as the project board, as well as the project manager and team manager roles.
It also covers a wide range of key project management themes – business case, organization, change, risk, planning, quality, and progress. Success on a PRINCE2 project is measured by how well it enables the project’s benefits to be realized by the customer organization.
PRINCE2 also includes a full project management lifecycle which explains which role takes key decisions at crucial times during a project.
PRINCE2 recognizes that on projects there are all kinds of products (outputs) produced by teams of people with various specialist skills. These teams have myriad ways of working and PRINCE2 does not try to guide how they should work.
Instead, PRINCE2 simply defines the interface between the project and these teams in terms of reporting, accountability, and the work to be done.
Who is Agile for?
History of Agile
Engineers in the software industry in the 1990s created Agile approaches when they were trying to address problems with software projects being consistently late, over-budget or delivering low quality software.
Today many industries outside the software industry use Agile approaches.
Focus of Agile
Agile approaches do not concern themselves with the wider questions about whether a project is worth it, or whether the benefits can be realized afterwards. They do focus however on delivering value to the customer by delivering products incrementally, in the most efficient manner possible.
These products are likely to do what the user/customer needs because the customers have been involved in a constant cycle of defining and prioritizing requirements, developing, testing, and providing feedback.
Delivery of working products
Agile methods are delivery teams doing the work - whether part of a project or not. They focus on questions for the team such as ‘what needs to be delivered next week?’, and ‘is the working software what the customer needs?’
One of the Agile principles is that people on teams must work together collaboratively with the customer. This is done by defining and prioritizing requirements, developing, testing, and providing feedback in a continuous and repetitive cycle of iterations. Often, the customer will be co-located with the development team.
Self-organisation by teams is also one of the Agile principles. Agile teams determine their own tools and techniques to use (e.g. task backlogs, burn-down charts, Kanban boards), rather than these being mandated by a project manager.
PRINCE2 and Agile comparison
One key difference between PRINCE2 and Agile methods is that PRINCE2 is often described as a predictive (plan-based) approach, while Agile calls for short-term, incremental achievements independent of an over-arching plan (the adaptive approach).
This means that, while PRINCE2 enables the customer to remain focused on the project’s original business goals, Agile approaches are very responsive to changes in the project environment and customer requirements.
Agile approaches assume that the development process is (predictably) unpredictable. They encourage complete transparency, close collaboration and frequent delivery of usable sub-products that will eventually contribute to the final product delivered.
Levels of plan
PRINCE2 has the concept of ‘levels of plan’. This suggests that different plans are required by different levels of the project management team. There are 3 levels of plan in PRINCE2:
- Long-term – this is a high-level project plan which is required by the key decision-makers (the project board).
- Medium-term – this is a stage plan required by the project manager for every stage of the project.
- Short-term – this is a team plan required by each team manager (leader) to cover the work done by their team. This is a detailed plan.
Sprints and timeboxing
Agile approaches such as Scrum, take this concept even further by suggesting a detailed plan for each ‘sprint’. A Scrum sprint is based upon the key Agile concept of a ‘time-box’ - a fixed period of time typically ranging from between 1-4 weeks.
Delivering working products
At the end of every Scrum sprint a Scrum team delivers working software to the customer. Delivering working software at the end of each sprint guarantees that the software is never delivered late.
The customer receives ever increasing increments of working software until, at the end of the final sprint, they receive the fully built and tested system.
Time-boxes and team plans
The Agile concept of time-boxes or iterations fits in neatly with PRINCE2’s concept of a team plan because there can be one or more time-boxes within a team plan.
PRINCE2 doesn’t prescribe how many time-boxes a team plan should contain because that’s a decision for the self-organizing Agile team members.
Responding to change
Cost of change
One criticism of more predictive project management approaches is that it is difficult and costly to manage changes. Changes are managed through formal change control processes, and decisions taken by a change authority.
In Agile approaches, changes can be done quickly. This is because customer requirements (e.g. software features) are described by the customer in the form of tasks which are prioritised in a backlog.
Because planning is never done further in advance than the next iteration (1-4 weeks usually), tasks can be quickly re-assigned a different priority, new tasks added, or unnecessary tasks removed.
PRINCE2 doesn’t have to be waterfall
There is a perception (wrong in my view) that PRINCE2 struggles to adapt to changing business requirements.
This view is based upon the assumption that PRINCE2 is a project ‘waterfall’ approach. A waterfall approach is where requirements are documented and approved before moving to a design phase, followed by a build phase and finally a testing phase.
There is nothing in PRINCE2 which prescribes such a waterfall approach. In fact, the latest PRINCE2 manual (2017) assumes that on many projects, requirements emerge and evolve as the project continues.
PRINCE2 manages such changes to project scope using its change control approach. However, lower-level changes, such as a feature requests can easily be managed at the team level using the prioritization techniques common in Agile approaches.
Using both PRINCE2 and Agile
The best of both worlds
Whereas PRINCE2 focuses on understanding what products are needed to support the business needs, Agile focuses on completing those products in an efficient manner, incrementally delivering more working software (products) as the work progresses.
Utilizing Agile approaches on PRINCE2 projects therefore can bring the best of both worlds – the structure and direction of PRINCE2, coupled with the flexibility and responsiveness of Agile.
PRINCE2 is not concerned with how teams organize or the methods they use. It does however define a simple interface between the customer organisation which is paying for the project and the supplier organisation which provides the teams which do the specialist work.
Business focus and timely delivery
This therefore means that teams on a PRINCE2 project can use any development approach they choose – including any of the Agile approaches. Providing they comply with the interface defined by PRINCE2, teams can utilize the benefits of Agile (such as on-time delivery), whilst the customer maintains the benefits of PRINCE2’s focus on the business justification.
Quick PRINCE2 and Agile comparision
|Useful for the customer to justify a project||Useful for the supplier to deliver working software|
|Focuses on higher management levels||Focuses on lower-level delivery teams|
|Answers questions such as “should we do the project?” and “are the benefits worth the costs and risk?”||Answers questions such as “what do we deliver next week?” “how will we know it (a product) is finished?”|
|More predictive approach||More adaptive approach|
PRINCE2 vs PRINCE2 Agile
In 2015, in recognition that many people were struggling to find a way of applying PRINCE2 on Agile projects, AXELOS launched PRINCE2 Agile.
PRINCE2 Agile is essentially the same as PRINCE2. They both rely upon the exact same principles, themes and processes. The only real difference is that the PRINCE2 Agile guidance explains in detail how to tailor these elements for Agile projects. In the PRINCE2 manual, there is only a cursory description of how to tailor PRINCE2 to Agile projects.
Fix or flex?
In particular, PRINCE2 Agile explains what to ‘fix or flex’ for the 6 performance targets of PRINCE2 (time, cost, quality, scope, risks, benefits).
For PRINCE2 Agile, time and cost are fixed. These cannot change. However, to be able to deliver what the customer truly needs, scope and the products’ quality criteria can be flexed.
What to flex must be agreed with the customer. Typically, to achieve this PRINCE2 Agile uses prioritization techniques such as MoSCoW, coupled with sprint backlogs.
The other 2 performance targets (benefits and risk) may be either fixed or flexed depending upon the customer’s needs.
Simply choosing to use a particular method or approach will never guarantee a project is always successful. In fact, any method or approach used without thinking will make a mess of any project.
The PRINCE2 focus on the business justification and whether a project is justified when the business environment changes remains its biggest asset. It helps to ensure that projects are based upon sound business sense.
The ability to respond quickly to changes with on-time delivery of products which deliver value to the customer is the biggest contribution of Agile approaches.
So, is it a matter of choosing either PRINCE2 or Agile? I don’t think so. If you are looking for a robust project management methodology to use on Agile projects, then PRINCE2 Agile fits the bill perfectly.
PRINCE2 Agile gives practitioners both the control and governance to guide the project, whilst at the same time it provides the agility and ability to deliver rapidly in a changing business environment.
AXELOS (2017). Managing Successful Projects with PRINCE2. 2017 ed. Norwich: The Stationery Office. 400.
AXELOS (2018). PRINCE2 Agile (3rd impression). Norwich: The Stationery Office. 338.