PRINCE2® in an Agile World

PRINCE2® in an Agile World

Over the past 30 years numerous methods, practices, and certifications gained prominence across the global IT community. As the numbers grew, so too did the tendency to promote specific practices and methodologies at the expense of other legitimate and relevant ones as all of them vied for their share of the market. This created the notion that they were competitors.

In North America the PMI dominates project management with many in the PMI community believing that PRINCE2 is a competitor to the PMBOK. The PMBOK is a Standard. PRINCE2 is a Method. The PMBOK is knowledge-based. PRINCE2 is focused on how to apply that knowledge. They are not only complementary, they actually need each other. I have given presentations to my local PMI community on exactly that topic as well as discussing how Agile fits with both.

Larry Cooper - Senior Partner, BSSNexus Global Inc.It has also been suggested by some that the Scrum Master role obviates the need for Project Managers. Scrum is focused on product development and does a really amazing job at it. Project management not only has to address product development (usually for software) but also for all of the other areas that are required for successful delivery such as procurement, infrastructure provisioning or the provisioning of training in the new product as part of its transition to operations. Without someone looking out for these areas and coordinating them, the actual product release may not go as well as envisioned.

The issue of choosing which practices are applicable to any given context is further exacerbated by the pace of change in the world around us. We have to stop trying to control change but, instead, start managing at the pace of change. This may be a challenge for many traditional management thinkers to overcome but less so for Agile practitioners who see change as a good thing, even late in development, as it enables them to better accommodate the emerging needs of the business. Managing at the pace of change requires us to critically assess our existing practices, not just in their applicability to our own context, but also to better understand their gaps and restrictions, and how they impede our ability to handle change at speed.

DevOps is a great example of blending different practices to solve a very real problem: you can’t have Agile teams delivering new capabilities on a once-a-month release cycle, nor can you continue to only allow the delivery of those releases into production a couple of times a year based on outdated SLA thinking.

Blending agile practices for software development with the ITIL® practices for change, configuration and release management, DevOps balances the needs of the business to get new capabilities or features into operations or to market sooner, with the competing priorities of the IT operations groups who are primarily concerned with stability, security and performance. Seemingly disparate at first, they have become strong allies in improving the stability and security of agile developed products while improving time to market.

With the creation of PRINCE2 Agile™, AXELOS has begun this critical re-evaluation and adjustment of its existing practices and methods to incorporate Agile. As part of that evaluation we will be releasing a new white paper called “Next Generation Agile and Value Delivery: Are you ready?” In it we will use a contextual model that we developed to discuss what the new realities imposed by the pace of change and the broad adoption of Agile will mean for value, portfolio, programme, project and service management practices. This has been based on the upcoming book “Agile Value Delivery: Beyond the Numbers”. It’s an exciting time to be in the industry; we’re seeing a fundamental shift in our models which, in turn, are precipitating even greater shifts in our thinking.

PRINCE2 Agile – the Structure

Blending Agile with PRINCE2 processes and themes will likely be a challenge for both PRINCE2 and Agile practitioners alike to fully embrace. Many may see it as adding a set of heavy processes to Agile. However, as they come to understand what PRINCE2 Agile offers both communities, we believe that they will overcome any initial scepticism and recognize the value PRINCE2 Agile brings to both. No-one thought you could blend ITIL and Agile but DevOps is proof that old practices can indeed find new friends.

As already stated, this is just the beginning of a broader push to integrate different methodologies and practices that will enable practitioners to get the most out of their existing knowledge and experience while they continue to identify areas for emerging practice – but with a very definite emphasis on incorporating Agile thinking throughout.

Looking at the new PRINCE2 Agile qualification I have two initial observations: the first is that it was long overdue. Many of us have long known that Agile and PRINCE2 could and should be blended. The second is now that we have done the blending, we know Agile and PRINCE2 are, in fact, quite complementary, just as PRINCE2 and the PMBOK are. A good balance has been struck between the two; the blend is far better than simply the sum of two parts.

The way PRINCE2 is structured will require a bit of time for those not familiar with it already to fully understand. For existing PRINCE2 practitioners PRINCE2 Agile provides specific guidance on where and how to incorporate Agile throughout their projects. While there may be some initial apprehension about imposing so much structure on Agile, doing Agile well takes discipline and good discipline occurs within good structure.  Scrum, for example, is quite structured while at the same time requiring a lot of discipline to do it well and is often blended with eXtreme Programming (XP) practices to address its lack of software engineering focus. Blending practices is not new in the Agile community.

Bringing PRINCE2 to the Agile Community

A large part of Agile is the terminology or, more specifically, not using certain terminology such as “control”, “manage”, or “direct” in the context of Agile teams. Some of this terminology is in PRINCE2 Agile which, on the surface, may seem to be a complete antithesis to Agile, but there is actually a lot more flexibility in it than it may seem at first.

For example, the business case in PRINCE2 is used as a control point to ensure that the project is still valid to the organization. At the end of each Stage the business case is reviewed and decisions made on whether to continue, modify the direction, or to stop the project. The Agile equivalent is to do a review of the product that has been delivered so far at the end of each Release. A decision is then made on whether there is additional value to be delivered, or whether the project has delivered enough at this time and therefore the project can be ended early. While the terminology is different, the goal is the same – ensure that value is still being delivered.

PRINCE2 Agile, via the business case, also brings focus to the benefits to be realized by the business by doing the project and therefore shifts the focus somewhat from just the delivery of good products. A product may be done well but still not be focused on the right things. Agile focuses on things being done well, hence agile practitioners evaluate success in terms of the products delivered rather than necessarily from an understanding of why the product is required.  A benefits focus ensures we do the right things and together they enable Agile teams to measure success more easily in terms that are more meaningful to the business.

The PRINCE2 Agile Approach

The PRINCE2 approach helps you to determine what products are needed to satisfy the business case; Agile projects typically focus on creating a single product and doing them well.  PRINCE2 Agile combines both perspectives to ensure you don’t overlook any required products and to use Agile for creating the products that are needed.

PRINCE2 Agile also contains a tool that will give practitioners a way to measure their gaps on their road to agility – demonstrating how far along they are in the adoption of Agile thinking while they are doing actual projects. It’s a hugely valuable tool that will increase practitioners’ ability to become more Agile.

The new product will inevitably bring passionate reactions from both Agile and PRINCE2 practitioners but the benefits to be gained from combining the approaches will bring true value – it may just be a case of opening our minds more.

For more information, visit the PRINCE2 Agile section of our website.

Current rating: 4.5 (4 ratings)


8 Jun 2015 Greggory Tucker
Alternate text
I will be very interested to see how they blend concepts from very different roots. For example, the Product Breakdown Structure assumes the product must be known and defined in depth by its components at Project Initiation, vs. the agile assumptions that products cannot be known in advance and that each iteration must result in a working version.

28 Jun 2016 Peter Jetter
Alternate text
I find it interesting, that Axelos perceives ongoing development (continuous stream of valuable changes) as routine. One could argue, that the discovery, development and creation processes are inherently complex and thus do not fit most definitions of routine or BAU.
IMO BAU is characterised not only by identical WHAT, but also identical HOW: identical input is transformed by identical procedure steps into identical output under identical conditions. This is hardly the case, when your input is always different and the output is always different (something NEW, which did not exist before) and you always need to collaborate in new ways to get it DONE. Discovery&Development is not Mass Production.
You must log in to post a comment. Log in