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 an 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 in Scrum to 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 – but typically most of the members of the Project Board don’t work on the project every day. Their involvement is often limited to their time on the Project Board. 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 miss-interpretation 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 miss-interpreted (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.