Can you combine Agile with Prince2 ®/ MSP? ®
Or perhaps the question is, why on earth would you want to?
There are people claiming that Agile can be combined with Prince2 ®. While we are not saying this is impossible, our view is that the approaches are quite simply incompatible and others warn this is more like mixing oil and water. I am not alone in this view. Mike Bracken, the Executive Director of “Digital in the Cabinet Office”, and head of the UK Government Digital Service (GDS) shares very similar concerns in ‘you can’t be half agile and argues that you will end up with the worst of both worlds if you try to combine Agile with Waterfall driven Governance. There is also a comprehensive analysis of the likely consequences of combining them both in a white paper by Roger Fance.
The largest challenges are cultural (and mindset) and few are more important than the ‘command and control’ basis of Prince2. Also, many Prince2 practices would have to change dramatically for the benefits of Agile to be realised. Prince2 is contrary to the principles of Agile and to the practices that deliver many of the benefits Agile can bring. Agile is not simply plugging Scrum into your development process. It goes far deeper than that.
Opposite ends of the spectrum: control versus flexibility
Change is looked on as a bad thing in Prince2 (hence the ‘tolerances’, strictly ‘controlled‘).
One of the major advantages that Agile can bring is the ability to accommodate change quickly (flexibility is a better word). Introducing Change in a Prince2 environment can be very slow (cumbersome, not ‘agile’) and is often a real challenge. Even to the point where it is avoided rather than embraced.
Another huge difference: decision-making cycles
Prince2 retains all key decision-making at the Project Board level. However, most of the members of the Project Board rarely work on the project every day. Their involvement is often limited to their time on the Project Board. This may be monthly or even quarterly. Monthly Project Boards can be very slow when there are issues and decisions are required.
The same thing will occur if you only call on the Board when an ‘exception’ has occurred. Agile looks to have decision-making (e.g. via Product Owner) available to the team all the time – to reduce delays, when decisions are required or there are issues to resolve.
and look at the evidence!
What’s the evidence of what we say? Here is one perfect example. It’s the disastrous results of when Agile was attempted in a ‘Prince2’ environment. Adopting Agile is a great deal more than delivering work packages using Scrum, on what is still a Prince2 ‘driven’ project.
Projects do need Governance and Management – but in a more Agile way
All business projects require strategic definition and governance. Again this is often a misinterpretation by proponents of Agile who believe all you need is a product backlog and off you go. This is a huge mistake but Prince2 is not the way to deliver Agile governance.
We also believe that Prince2 is not best practice at all. However, we do believe it is totally possible to bring much more effective management and governance to all projects, but in a far more Agile way.
Comparison of core values in the ‘Agile manifesto‘ & Prince2:
| Agile Values/Principles | Agile Practices | Prince2 | Comments |
|---|---|---|---|
| Individuals and interactions over processes and tools | Agile favours face-to-face communication at all times. Agile uses single flat teams with all required decision making inside or available to the team | Prince2 relies heavily on written reports and documentation, which are a classic form of one-way communication. One-way communication carries risk and frequently results in issues. It also results in delays and re-work, versus more collaborative projects. | Prince2 retains separation of responsibilities between project boards and development teams, typically with monthly (or longer) meeting cycles for project boards. Agile requires daily interaction (including the Product Owner) to enable timely decision making. |
| Customer collaboration over contract negotiation. | Co-located teams, with product owners actively participating in the project. | Project boards, who only become actively involved when the project is out of tolerance, meaning serious issues have occurred. | If it was your own money, which of these would you prefer? |
| Business people and developers must work together daily throughout the project. | Daily face-to-face stand-ups, daily updates on progress (e.g. burn-down) and daily communication around impediments to progress. | Management by exception, monthly reporting (usually written is most common), and business people become involved once significant issues have occurred or are expected to. | Management by exception does not motivate teams or project managers to highlight issues early. No PM wants to flag-up an exception, and human nature will too often prevail. Using Agile methods. progress and issues should be highlighted in real-time and very transparent. For example, story points are either complete or not. Simple, and clear. In 'traditional' projects, it is too easy for teams to decide themselves how open they wish to be. |
| Responding to change over following a plan. | Frequency of iterations and planning within Agile allows flexibility seldom found in other approaches. | Prince2 expects scope to be fixed and uses the mechanism of tolerance to 'control' scope. Anything outside of this is a change control board issue. | Change control boards are a very slow way to implement change and often involve significant bureaucracy. This does not motivate people to contemplate change and go through its 'justification', It does even deter people from proposing change when that's exactly what is needed. |
| The most efficient and effective way of conveying information to and within a development team is face-to-face conversation. | Team organisation and team practices facilitate face-to-face conversation. | E.g. Checkpoint Reports, End stage assessments, Exception & Highlight reports – the list goes on. Take a look at the documents listed here - quite staggering and totally overwhelming. | Agile favours practices that enable and encourage two-way communication. Prince2 is heavily reliant upon written reports, a far less effective form of communication, which is the most common source of issues on projects that we know of. |
| Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done. | In an Agile project, there is a single team, with the decision making authority available to or within within the team. | Project boards, outside the core team, retain responsibility for the project. Project managers are there to simply report to the board. | Prince2 Project boards often operate very much at arms-length to development teams. This is a long way from the collaboration that is encouraged in Agile. |
| Simplicity - the art of maximising what is not done, is essential. | Retrospectives, using an Agile approach to all aspects of the project. | Set-in-stone processes, process compliance, audit and independent assurance. | Organisations that love (or can't operate without) bureaucracy will feel very comfortable with Prince2. Those who want to find the best and simplest ways to get the job done will favour Agile. |
The above is just a snapshot of some key differences in ‘practices’ found in Agile and Prince2 environments. Some of them are worlds apart and need to be fully understood and faced up to if any organisation is to see the potential benefits of using a more Agile approach to managing its projects.
Also, a note on Agile – many businesses have attempted to adopt Agile and have misinterpreted (often shied away from) the most valuable aspects of Agile. Agile is not just adopting Scrum. Also, projects should never ‘begin with a product backlog’, as some Agile purists would say.
* MSP = Managing Successful Programmes – methodology for programme management from the same stable as Prince2.
PRINCE2 ® & MSP ® are registered trade marks of AXELOS Limited.
Share this:
3 Comments
Leave a Comment
Contact Us Now
EMAIL us today.
Or call ++44 (0)1865 784040
I am known Agilist and Lean and Scrum expert. I am also PRINCE2 and MSP certified. I have introduced Rapid Application Development in enterprises in mid 90s.I got officially involved in Agile in 2001. I also ran large global programmes beyond 100M USD.
I do not find PRINCE2 non-agile by necessity. But maybe that is the way I approach things, from a Lean and Agile perspective. Some people complain about SAFe, one of the scaling agile frameworks. As a Lean and Agile coach, I would tailor.
So I’d tailor PRINCE2.
A lot of what I do is Scrum or Kanban based, supplemented by XP and Lean. These are by intention frameworks, incomplete.
I am not looking for a heavy framework / methodology on top. But I do not see PRINCE2 necessarily as heavy.
In a lot of cases it may give me more than I need.
There are cases though, where tailored PRINCE2 combined with Scrum/XP can be a fit.
It could be when we have a programme, where some teams use Scrum but are dependent on other teams – e.g. vendor or hardware teams or COTS teams using more traditional delivery.
I have done such combinations. And you need more than Scrum Masters. You need at least a savvy Agile PM / Prgramme Manager. Reason why SAFe calls the Release Train Engineer an Agile Programme Manager.
PRINCE2 may be better understood by the outside world, when not transformed yet to Agile. PRINCE2 tailoring helps. Management by exception helps. Work Packages help. If all runs well, the board has nothing to do.
It is important to let the Scrum teams self-organise.
I would use PRINCE2 in Agile by exception.
I am also not a fan of PMI-ACP. But I see an easier fit for PRINCE2. I do not find PRINCE2 non-agile. But which parts do I need in practice, when I have Scrum/XP/Kanban/Lean/Agile Product Management?
I can DIY leaner and more agile.
Hi Adrian
Many thanks for your comments. I thought it worth saying:
1. Prince2 is not non-agile by necessity but is not lightweight (in terms of no more than necessary) without a great deal of tailoring. In terms of the behaviours it can encourage (albeit not intentionally), I have real reservations. I know businesses and business leaders who would remove such doubts entirely at source.
2. Many who are used to Prince2 are not going to approach things from a lean perspective – especially in many elements of the UK. Possibly why you personally don’t see P’2 as heavy.
3. In the UK, the project board often has a lot to do. When this occurs, things can get very slow and heavy.
4. I totally agree that in many if not all cases you need more than Scrum masters, but by using methods that work really well and are no more than needed.
5. One of the biggest issues we have in the UK (may be cultural), is that MBE (in a number of environments) does not really work at all. It just slows down the release of bad news so much any opportunity has vanished. That may sound a little harsh, but in our experience (and we interact with dozens of sizeable organisations every year) things over here in recent years are getting worse not better. We (in the UK) really do not have a culture of disclosure. I do totally agree that if you are running a £100M project you have to use a form of MBE, but my issue is that expecting project managers to highlight an Exception is like asking turkeys to vote for Xmas. In the UK too often, they will, but only when they have no other choice but to do so (reality-v-training course).
6. Lastly, and this may be one of the biggest issues I have, is that (certainly in the UK) Prince2 is taught as if the method is ‘perfect’ and if people don’t follow the method they are just ‘wrong’. There were comments today on a LinkedIn discussion on this very subject to underline this.
Prince2 is a framework and if it is really ‘sold’ and seen as such and no more I would have no issue. I do have a huge issue with it all being tailorable yet being so comprehensive. I do not find that reasonable or fair as a supposition or to the people who are being trained or introduced to the method. To add that concern to a Prince-Agile, for me is a step too far.
Hi Adrian, These are interesting comments, but I really struggling with mixing PRINCE2 (control based and linear in execution) with Agile (devolved and iterative). For me, it’s horses for courses. I can’t see a bridge being built in an iterative way, neither could I see a service transformation being linear. They both have validity in different contexts, although there are much better linear approaches than PRINCE2.