With PRINCE2 Agile, the victim is Agile – Part 1

Let’s start with a question.

Which would you rather your organisation were more like:

1. the British Civil Service; or
2. a product innovator capable of out-manoeuvring a superpower’s market leaders?

To boil it down to simple choices:

if a) then choose PRINCE2 and forget Agile. Actually, even then PRINCE2 may not be a good way to go.

if b) then choose Lean Product Development, Scrum, Agile and forget PRINCE2.

The question here is can you actually be both without having each irreconcilably compromise the other?

In this blog post, we explore some of the apparent conflicts in PRINCE2 Agile and pose some key questions for leaders that these issues present.

PRINCE2 is a very widely used project management method in the U.K., a number of European countries as well as Australia and New Zealand. Those in the U.S. might consider it to fill a space similar to the Project Management Institute’s PMBOK in those countries.

To be clear, PRINCE2 is perfectly good for what it is designed to do for the organisational context and project control characteristics that it is designed to achieve. From an organisational culture perspective, it is wonderfully aligned with a Hierachy/Control culture. In Cynefin terms, its predictive and centralised control approach is likely a good tool for project-based initiatives that are limited to the Complicated space but not where there is substantial exposure to Complex space. Purporting to be appropriate for being Agile raises the question: how does PRINCE2 Agile look from an Agile perspective?

It is insightful to critique PRINCE2 Agile from an Agile and Scrum perspective as it illustrates the many ways in which Agile and Scrum are misinterpreted from a traditional project management or Tayloristic mindset and provides specific examples of what Scrum is not. I did a similar thing in 2016 when I did a presentation called Illuminating the potential of Scrum by comparing LeSS with SAFe.

In Part 1 of this series I share a little of my background in relation to combining PRINCE2 with Agile/Scrum and we discuss apparent conflicts in the contrasting control approaches of PRINCE2 and Scrum.

My background with PRINCE2 and Agile

Combining Agile with PRINCE2 has been a perceived need for some time

I have been Scrum Mastering, coaching, delivering CSM courses and consulting around Agile adoptions in a PRINCE2 environment since 2003 and became PRINCE2 Practitioner accredited in 2009. I have not undertaken the PRINCE2 Agile training or exam but did read the PRINCE2 Agile manual shortly after it was released in 2015.

In 2007 I founded an Agile interest group in Canberra that met monthly. The most popular topic at the time was: How do we get Agile to work in a PRINCE2 environment. This was probably not surprising given that PRINCE2 was used on the vast majority of Federal Government projects in Australia’s Federal capital. PRINCE2 experts from the city’s leading PRINCE2 training provider spent the first three sessions talking about how PRINCE2 could be blended with Agile. The proposition was that some elements could be thought of as brothers and sisters, some parents and some cousins.

The finding that buoyed the PRINCE2 proponents was that a fairly clear mapping could be identified between the PRINCE2 processes and artefacts and Scrum or others that were used under the Agile umbrella. 8 years later, the PRINCE2 governing body came out with the same view in the form of PRINCE2 Agile.

Tellingly, the discussions that we had in 2007 skirted around the thornier aspects of how roles and accountabilities mapped and didn’t dive deeply into comparing values and principles. I later came to realise that this approach, and the sense of coherence that PRINCE2 advocates got from it, was entirely logical given their background and mindset. “PRINCE2 is a process-based approach to project management” that specifies numerous documents to be used as internal contracts and other control purposes inside a project. Our discussions looked at the situation through the lens of processes and documents. Basically:

Processes and Tools over Individuals and Interactions

and

Comprehensive Documentation over Working Software

PRINCE2 constrains ability to be Agile

In the years since I have walked into several organisations attempting Agile adoption where PRINCE2 was already in place and perhaps mandated. In each of these, the PRINCE2 governance has constrained the Scrum adoption from realising many of the more impactful improvements. That was despite limiting the PRINCE2 implementation to the governance level and not including the project management elements. PRINCE2 Agile insists on implementing all of project management as well as governance aspects of PRINCE2. I would, therefore, expect the Agile capability to be more constrained with PRINCE2 Agile than what I have experienced.

Even without the Project Management layer of PRINCE2, I have generally seen Agile being reduced to little more than incremental development whilst trying to keep “on track” to an overall plan. Many of the conflicts between Agile and PRINCE2 that I’ve seen over the last 15 years are evident in the definition of PRINCE2 Agile as defined in the PRINCE2 Agile Manual.

PRINCE2 Agile is more of a set of guidelines for tailoring PRINCE2 to work in an environment with some of the trappings of Agile rather than a new method. Which Agile practices are enacted is left quite ambiguous. Rather than describe a desirable direction for Agile practice, the PRINCE2 Agile manual reads like a guide for a Project Manager to navigate the existing level of Agile maturity with little view to improving it. Presumably, that’s for the ScrumMasters although if a ScrumMaster were to follow-through on even the first responsibility of the role as originally described i.e.

“Remove the barriers between development and the customer so the customer directly drives development”

I would expect that the Project Management layer of PRINCE2 Agile be identified as a such a barrier!

Conflicts in the Control Approach

Perhaps oddly, PRINCE2 Agile shuns stable mate DSDM Atern (and the AgilePM subset) in favour of attempting to “blend” Scrum and Kanban with PRINCE2. Given that DSDM Atern is a more PRINCE2 aligned method than Scrum and Kanban, the PRINCE2 Agile result represents more conflicts the classic PRINCE2+DSDM combo. Given that PRINCE2 Agile incorporates Scrum terms and concepts extensively, the following discusses alignment with Scrum specifically and not just Agile.

Radically different origin contexts

The direct predecessor to PRINCE2 was PROMPT which originated in the British Civil Service in the mid 1970’s. PROMPT was a waterfall model with 6 activity-based phases.

Scrum (emphasised by PRINCE2 Agile) was patterned after innovative automotive and consumer electronic product companies in Japan that were out manoeuvring the USA.

Questions for leaders

1. Which would you like your organisation to be more like: the British Civil Service or a product innovator capable of out-manoeuvring a superpower’s industry leaders?
2. What does that mean for your choice of operational model for product innovation?

Conflicting management paradigms

Whilst PRINCE and PRINCE2 dropped the waterfall-style phases, they retained the Plan-Delegate-Monitor-Control (PDMC) project management cycle through to the current (2017) version. This is very much an instantiation of neo-Tayloristic management with its roots in the Industrial Revolution.

In contrast, Agile methods such as Scrum and Kanban were born out of the Lean management paradigm with roots in W. Edwards Deming’s teachings and principles. These represent a radically different approach from mainstream Western management and, despite the obvious success of the Toyota Production System, remain elusive to most Western organisations.

With its emphasis on people (not fungible human “resources”) Agile can also be an expression of people-centric approaches such as humanistic management.

Questions for leaders

1. Have you studied how much of your current management systems and culture is based on Taylorism?
2. How familiar are you with Lean and humanistic management?
3. Which management paradigm will afford you most chance of success into the future?

Conflicting control models

Control is so central to PRINCE2 that it’s embedded in the name i.e. PRojects IN a ControlledEnvironment (emphasis added). As a current overview of PRINCE2 (pdf) describes:

“PRINCE2 uses stages and tolerances as its major elements of control. Tolerances allow for a management by exception approach, i.e. only involving the project board for making decisions when the project tolerances have been exceeded. Stages are used to keep the management of project appropriately supervised and documented for those directly involved, for example the project board members and the project manager.”

“Tolerance is the permissible deviation above and below what has been planned” where “what has been planned” refers to planning prior to development. The “Monitor” component of PDMC involves the Project Manager monitoring for deviation from what was planned with escalation to the Project Board if it exceeds the set tolerances. This is classic defined process control based on the up-front prediction/plan. As such it directly conflicts with Scrum’s empirical process control approach.

In PRINCE2 Agile, a Project Manager is assigned the accountability of managing a project to the agreed plan. At the same time, it is expected that the same project will “be Agile” by using Scrum which intrinsically involves re-planning based on the emerging reality. In a non-trivial project environment, this invariably involves deviation from the up-front plan and you have a fundamental conflict in terms of:

Following a Plan over Responding to Change

Essentially, in PRINCE2 Agile the Project Manager still controls the project to the direction of the project board. This leaves no room for a Product Owner or Scrum Team to genuinely steer Sprint-to-Sprint. This breaks any attempt at genuine Scrum (which isn’t just a delivery method).

Questions for leaders

1. Do you see a fundamental conflict in asking for adaptability with Agile whilst implementing top-down control relative to up-front plan as per PRINCE2?
2. Will initiatives in a space of substantial uncertainty and complexity be more successfully managed with: a) an upfront plan and monitoring for conformance to plan within tolerances, or b) with frequent first-hand inspection by key stakeholders and adaptive management?

PRINCE2 Agile makes The Contract Game likely

The PRINCE2 Agile manual says that “Scope and quality criteria are the primary focus of any tolerances used.” Given that time and cost are strictly fixed with PRINCE2 Agile and tolerances are set upfront prior to development, a lot of flexibility with the scope tolerance would appear to necessary for any meaningful ability to steer in an Agile way. The guidance is to have “Zero tolerance for products that are essential” with some flexibility for “products that are desirable but not essential”. The first constitutes fixed scope setup and with the latter, there is likely to be substantial pressure from stakeholders to categorise as much as possible as essential. The dynamics of negotiating scope and date upfront with competing interests between business and development groups have been described by Craig Larman as part of The Contract Game. The competitive nature of this game conflicts with what Agile is intended to be: a co-operative game.

Question for leaders

1. Are you interested in breaking your organisation out of the competitive Contract Game whereby business can directly steer directly throughout rather than relying on control to be exercised through up-front internal contracts?
2. Are you prepared to demonstrate trustworthiness and lead toward a high trust environment where ownership can be delegated to an entrepreneurial business person who listens, takes advice and collaborates directly with development?

Containing Scrum like firemen contain a bushfire

Like SAFe, PRINCE2 Agile wrappers Scrum which is contained to be exploited as just a “delivery” approach. Keith Richards explains the rationale for this (video) as: “Most Agile – Kanban and Scrum – have nothing to do with project management… There is no project management in Scrum or Kanban… You have to wrap them with some form of project framework, like PRINCE2.”

In wrapping Scrum with the full PRINCE2 method, PRINCE2 Agile keeps to heavy bureaucratic control and misses the opportunity to achieve agility by largely replacing this with market and clan/team control as is achievable with Scrum (see slides 55-58).

(Thanks to Michael James for the bushfire/wildfire analogy.)

Plan driven from Project Board down

PRINCE2 Agile requires a project plan early in the project that provides “a baseline against which progress can be measured and stages defined”. This plan “may be more formal and show dependencies” and the stage plans within it “may also be quite formal”.

In PRINCE2 Agile, the Project Board approves a Stage Plan. In practice, I have repeatedly seen this done as a Gantt chart that ties particular deliverables with milestones. The Project Manager is tasked with monitoring and controlling according to this plan, reporting to the board.

In my experience, PRINCE2 stage boundaries are usually managed in order to remain “on schedule” to deliver on the overall project plan. In such a context, any Sprint Reviews that may occur become an exercise in assessing progress and not a genuine attempt to adapt the direction of the product’s development. After all, when you’re busy just trying to keep up with following a plan, there’s little appetite for adapting to new ideas that may keeping “on schedule” more difficult. If there is no Product Owner actively making whole-of-product decisions to maximise value, and the Project Board are not present at Sprint Review, then there’s little chance of substantial adaptation coming out of Sprint Reviews anyway.

Conclusion to part 1

PRINCE2 Agile emphasises following a plan set up-front (with tolerances) over responding to change. In PRINCE2 Agile we have all of PRINCE2 with modest tailoring rather than a substantial rethink of PRINCE2 in lights of how Agile principles impact its arms-length governance and control by a project manager. This puts brakes on Agile in such a way that a Scrum implementation is broken.

My experience suggests that when attempting to combine PRINCE2 with Scrum, limiting the PRINCE2 implementation to the Governance (Project Board) layer only with substantial tolerances (particularly for scope) is less limiting on a Scrum implementation than what PRINCE2 Agile describes with the full Project Management layer also implemented.

In Part 2 we discuss how PRINCE2 and Scrum (mis)align in terms of organisational design including roles and authorities.