The marriage between PRINCE2® and agile – An ATO’s view

  • By Ray Mead, CEO, p3m global
  • 21 July 2015
  • Agile, Behaviour, Portfolio Management, PRINCE2, PRINCE2 Agile, Programme Management, Project Management
The marriage between PRINCE2® and agile – An ATO’s view

It was the marriage they said could never happen but AXELOS has managed it. What were thought to be two polar opposites, PRINCE2 - symbolizing control, accountability, order – and agile – symbolizing self-organization and equality, have been reconciled in the new PRINCE2 Agile™ guidance.

What is perhaps most surprising about this is how relatively few feathers have been ruffled on either side of the fence. A PRINCE2 vs agile conversation can escalate quickly in certain circles, as testified by the many heated discussions you will find across project management-themed internet forums. Yet beyond the outlying apprehension, there has not been an almighty wave of backlash greeting PRINCE2 Agile. This has been in no small part down to the amount of thought and consideration Keith Richards and his team have put into this. By thoroughly examining and honouring the ethos of both schools of thought they have shown how they can be thought of as natural bedfellows. What’s even more surprising and, indeed impressive, is that no principles on either side have been compromised; no square pegs have been forced into any round holes. Remarkably, nothing in PRINCE2 has had to be surgically removed in order for it to work in an agile context. All the principles, themes and even processes remain. For this feat alone, the authors deserve applause.

Ray MeadThis leads to the wider question, then, of what agile and PRINCE2 are if they are not diametrically opposed methods or frameworks. It is often said that you don’t DO agile, you ARE agile – it is about the behaviours you and your team display to get the job done. In this way PRINCE2 Agile defines five commonly recognized agile behaviours to complement the principles and themes of PRINCE2. So in modifying our behaviour we can work in an agile way but still in controlled environments and without compromising quality.

The way I have always looked at agile is, rather than it being a state where you are either agile or not, it is rather like a spectrum, or a pendulum. On one end of the spectrum are the more process-driven frameworks such as DSDM and at the other end, lacking process of any sort, some might call chaos (albeit self-organizing chaos!).

It’s good to see that PRINCE2 Agile has acknowledged this by incorporating the concepts of the Cynefín Framework; which provides a way of altering behaviour based on the situation you find yourself in; and the Agilometer, a way of assessing the risk of using agile in the environment you are operating in.

Both of these concepts together can help us to make decisions about when it is right and appropriate to use agile or to behave in an agile way, which is precisely what most of my clients are struggling with. Coming back to the pendulum analogy, many of my clients at p3m global, convinced or curious about the benefits of agile, have thrown their teams or even their companies behind it with varying degrees of success. On some occasions they swing the pendulum from extreme left (tight compliance) to an extreme right position (tearing up all the plans) and it has blown up in their face. The main reasons for this are usually:

  1. They have not prepared for a culture change or parts of the company do not ‘play along’
  2. They set up and monitor the wrong metrics (“we are on time and on budget on all projects but have no idea of the benefits we’ve realized”)
  3. They ‘pick and mix’ from agile but fail to implement some of the fundamental tenets, such as open communication
  4. They use ‘we do agile’ as an excuse for laziness or lack of customer focus
  5. They don’t give it long enough, i.e. reverting to old habits after failing to make an impact on the first few sprints.

In each of these cases, the initiative fails, but they are missing the point. Instead of tearing up the rulebook, a better approach would be to ask ourselves HOW and WHEN can we BE more agile.

This is where Gartner’s Bimodal IT model is a step in the right direction but doesn’t go far enough, implying that agile is a switch to turn on for certain type of projects. In most modern organisations the challenges being faced are more complex than that and require more sophisticated ‘multi-governance frameworks’ to flex the level of process control required as well as highly skilled people to anticipate, react and adapt to this style of work and management.

Both PRINCE2 and agile are all about trying to make sense of people working together and where there are relatively few co-located people focused on a single initiative then, nine times out of ten, an agile approach would undoubtedly be the preferred option. PRINCE2, however, is primarily an organizational method, allowing diverse sets of people to speak a common language and follow a single path, so in this case PRINCE2 can offer agile one route to achieving the organisational scale it needs to be truly adopted into the corporate culture.

If ‘traditional’ P3M (project, programme and portfolio) governance structures adopt agility as a new paradigm, aiming to be more agile when they need to, the result would be faster and better decision making and an acceleration of the business planning cycle leading to real competitive advantage in the marketplace.

The irony then, is this: agile without control might be chaos, but good control makes you agile.

Have you used both PRINCE2 and agile methods to manage the same project? What did you find were the most valuable aspects of each for the goal you were working towards? Please share your thoughts in the comments box below.

Current rating: 5 (1 ratings)


22 Jul 2015 Nico Viergever
Alternate text
I see Ray’s points about PRINCE2 Agile but I do not entirely agree. PRINCE2 Principles are broken in this extension. Agile is not really agile when it follows an old dogma from the Command-and-Control World.

For anyone who wants to see it, there is plenty of proof that one of the most important reason for failing projects is in fact the focus on time and cost as demanded by the old-fashioned Command-and-Control world. In his standard work on “project-based work” J.Rodney Turner wrote about research in Australia in (if I remember well) the early 1990’s. In that research hundreds of projects were looked at that all finished on time and to budget. Five years later these projects were all, without exception, seen as failed. This is a very strong indication that the focus on time and cost is breaching the PRINCE2 Principle of Continuous Justification.

The man behind the Japanese quality movement, Dr.E.Deming also made quite clear that focus on cost/time, efficiency and standardization will only lead to higher cost because of a lack of quality; a breach of the Principle that focusses on Products (and their quality). Also Eli Goldratt (The Goal) presented this view. Local efficiency leads to ineffectiveness. Eli Goldratt introduced the term “Cost World” for this old-fashioned ineffective thinking.
In the same direction: we all know that the majority of cost (60-80%, a conservative estimate) of a product is spent during maintenance and support. So why would anyone want to increase this percentage by lack of quality during a project by focusing on time and cost? Basically another Principle is breached: learning from experience.

I always presented PRINCE2 as a very agile way of thinking. With the tolerances, the management stages and the continuous justification, high level/detailed planning and re-planning, for me there is no other way than an agile approach. But real agile; not this time-boxing/low-quality, “short-term cheap / long-term-expensive approach”.

Conclusion: the focus on time and cost is contra productive. And what does (PRINCE2) Agile propose? “Be on time and hit deadlines”. Just silly; so against PRINCE2; so against really agile.
6 Aug 2015 Allan Thomson, AXELOS PPM Future Product Lead
Nico raises some very interesting points. PRINCE2 says there must be an on-going business justification for the project and so too does PRINCE2 Agile. We all know of examples where entry costs are low but maintenance costs are high, home printers are often cited as an example of this. The cost of the printer is relatively low but the cost of the ink cartridges are not. That is why the business case should look at whole lifecycle cost and not just the cost of project itself.

PRINCE2 makes this explicit when it says, “The costs should also include details of the ongoing operations and maintenance costs and their funding arrangements.” So while PRINCE2 Agile is looking at the interface between PRINCE2 and agile delivery approaches it still expects there to be an ongoing business justification for the overall project concept including operations (running costs) and maintenance. In any project there should be budget control whether the work package is delivered using agile or not.

The agile literature does place greater emphasis on being on time and on budget yet flexing the features. Within that context combining with PRINCE2 which provides focus on products, their quality and threats to those products included the project product itself, balances the narrow focus on time and cost and seeks to protect the quality of the projects products.

The discussion in PRINCE2 Agile seeks to explore how tolerances for the 6 parameters identified in PRINCE2 work in an agile environment; while the guidance was being drafted we had many an illuminating discussion around consequences and we always levitate back to what the project was meant to deliver. By that I mean the features not the quality. That is why quality criteria can be part fixed and part flexed depending on what the required output is.

I think we have all worked on projects where the requirements are a long wish list of features all set as mandatory. This is generally unrealistic, how many of us use all the features of our existing software packages, very few I believe. So the concept of MOSCOW becomes very important in helping us identify the must have requirements and those that we are less concerned about or less willing to pay for. In this way the quality of the products can be protected.

Both PRINCE2 and agile approach place great store in learning from experience not as a one off at the end of the project but throughout the life of the project seeking to continually learn and improve our ways of working. Various sources can be used for this not just with in our own organisation but from others who have done similar things. For example the London 2012 Olympics sought to learn from the experience of the Beijing and other venues.

To me PRINCE2 Agile, by interfacing two approaches both of which place great emphasis on learning from experience, hardly seems to be breaking a PRINCE2.
You must log in to post a comment. Log in