With PRINCE2 Agile, the victim is Agile – Part 2

Part 1 outlined my experiences with Scrum in a PRINCE2 environment and outlined a number of conflicts betweenPRINCE2 Agile and Scrum as well as Agile principles. In Part 2, we look at likely conflicts from a roles and organisational design perspective.

Conflicting Roles

Conflicting Roles and Accountabilities

The PRINCE2 Agile manual specifies that “all of the (PRINCE2) roles apply when using agile and their responsibilities do not need to change”. Given that these PRINCE2 roles enact control relative to plan (as per the PDMC doctrine), this represents retaining structures designed to implement a non-Agile organisational design whilst expecting an Agile capability despite those structures.

Whilst PRINCE2 and Scrum appear to map to each other reasonably well at a process and artefact level, they are full of conflict at an organisational design level – especially when the full authorities of the Scrum roles are respected. Specific examples include the following.

Conflicting with Development Team accountability

PRINCE2 Agile requires a “team manager or equivalent who is ultimately accountable for the delivery of a team’s products”. This breaks the ability to have the team accountable for its own delivery as required in Scrum. As the Scrum Guide says: “accountability belongs to the Development Team as a whole”. It also sets up an environment likely to result in a “work group” rather than a genuine “team”.

Conflicting approach to project management

PRINCE2 Agile requires a Project Manager role. This breaks the ability for the full Scrum Team (Product Owner, Development Team, ScrumMaster) to share the activities of project management. Through a modelling exercise, I have had thousands of CSM training participants come to their own conclusion that adding a Project Manager role to what is managed with Scrum would lead to close to 100% overlap with the fully-fledged Scrum roles.

Product Owner conflicts

Product Owner role misinterpreted and limited to tactical (if implemented at all)

PRINCE2 Agile incorrectly (re)defines the Scrum role of Product Owner role as “The role assigned to managing the product backlog in order to get the most value from it by ordering and prioritizing it”. The Scrum Guide’s definition of Product Owner starts: “The Product Owner is responsible for maximizing the value of the product” (emphasis added). This is enormously different.

The PRINCE2 Agile manual claims that the Agile equivalent to a PRINCE2 “Senior User” role is a “super product owner”, “senior product owner” or “product manager” and that the Product Owner role does not map to this high-level customer view role. It appears to imply that this is because the product owner is found in a development team.

Product Owner role replaced with an SME or business analyst

Section 10.5.2.2 “The simplification of the product owner role” of the PRINCE2 Agile manual argues against a single product owner role because a project is too complicated, and the product owner role can be too much work. Also “a project requires many customer roles in order to correctly reflect the customer’s view.” A decade of successful implementations of what is now called LeSS (Large-Scale Scrum) is an existence proof that this thinking is flawed. Instead of a single Product Owner for a project, PRINCE2 Agile recommends roles such as “customer subject matter expert”, “requirements engineer” or “business analyst” (possibly in the project management team).

Committee vs involved individual

Committee based steering conflicts with Product Owner steering

Most key decisions about the direction of the project are made by a steering committee (called the Project Board). If Scrum is implemented, this conflicts with a single Product Owner steering – potentially with input from a committee – as described in the Scrum Guide:

“The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

Committees often reach an agreement through compromise. Roman Pichler questions the committee approach in his book ‘Strategize’ with the suggestion that “great products are not built on weak compromises”. Also, the saying:

“A camel is a horse designed by committee.”

PRINCE2 proponents may argue that the PRINCE2 Project Board represents a governance function exerting control using a budget, go/no go approval, etc. mechanisms at a strategic level whilst the Product Owner role performs a delivery function at a tactical level. This represents a widespread misunderstanding of the Product Owner role that diminishes it to the tactical level rather a strategic entrepreneur with whole-of-product steering and Return on Investment authority. Product Ownership expert and author Roman Picher, describes this as the difference between a “Small Product Owner” and a “Big Product Owners”.

Question for leaders, which model do you expect to lead to a more successfully balanced and impactful product/solution:

1. A committee of diverse interests; or
2. An accountable and entrepreneurial leader who seeks advice and owns the benefits realisation?

Decision making cycles overly long for meaningful agility

The PRINCE2 Project Board committee meets infrequently upon stage boundaries which are typically months apart. Also,when a tolerance is breached relative to what was planned. Convening a Project Board of managers who are infrequently involved in the project typically involves some scheduling delay

There is nothing in PRINCE2 Agile to suggest that they fold their meeting in with Sprint Reviews. Even if a project board was to meet on a regular monthly cadence to steer the direction of the project, they would be making decisions based on reports and not from the first-hand inspection of the product/solution and the feedback from users and other stakeholders as per Scrum.

In my experience, the majority of the Project Board members spend most of their time working on matters other than the project and have an arms-length relationship with those working day-to-day on the project. They don’t interact directly with team members and instead rely on written reports from a Project Manager or the like.

As Certified Scrum Trainer Karim Harbott recently posted  the underlying assumptions of traditional project governance appears to be:

1. It is possible to know up-front the best things to build
2. It is possible to know up-front how long those things take and how much they will cost
3. Centralised bureaucracies, removed from the customer and the work, are best placed to pick winning ideas
4. Things will change very little as we progress
5. It is sensible to place big bets and to validate our assumptions after the money is spent

None of this aligns with Agile thinking, or arguably the majority of non-trivial systems development efforts in today’s world.

This may be ok for infrequent intervention in a relatively stable environment but when the environment is less stable with increasing levels of volatility, uncertainty, complexity and ambiguity, this approach is increasingly inadequate.

This approach of setting tolerances up-front and only intervening when a tolerance is breached allows control by approval to be projected up a hierarchy where senior managers/executives use these mechanisms to keep direct control over resource allocation rather than entrust it to people closer to the customer and product context. More aligned with an Agile organisation would be for executives to work on culture and business-level strategy rather than meddle below product strategy into whether particular projects are “on track” according to internal scope and date contracts.

Agile product development approaches such as Scrum suggest that the aim should be to optimise the value given emergent information. Given that hundreds or thousands of trade-off decisions over a calendar year may be required to achieve this, the relative “set and forget” nature of management by exception is clearly inadequate for this. A much more full-time engagement is required by someone who understands the value trade-off equation as is able to make frequent decisions across multiple dimensions of the investment vs value trade-offs, product quality etc.

Of course, delegating to an individual with business acumen who actually “own” the product strategy and actively steer development whilst taking advice requires trust. Executives would be well placed to focus on building a culture where trustworthiness is valued by modelling that themselves.

Questions for leaders

1. Do you believe that an arms-length management approach of “set and forget” until a tolerance is breached continues to be most effective for managing innovation initiatives as volatility, uncertainty, complexity and ambiguity grow?
2. Do you believe that direct and frequent business – development collaboration will lead to better results?
3. Do you believe that a high trust organisation will out-perform a low trust one?

Progress reporting conflicts

Misaligned measure of progress

Curiously, for a project management method heavy on progress reporting, the PRINCE2 Agile manual says little about how to report progress in a way more aligned to Agile than is typically done in PRINCE2.

The norm for Project Boards is to focus on reports relative to an up-front plan – typically in Red Amber Green (RAG) format. This is misaligned with viewing progress in terms of value identified through first-hand inspection as per Scrum’s Sprint Review. It is also misaligned with the principle in the Manifesto for Agile Software Development:

Working software is the primary measure of progress.

This isn’t just about a quantitative assessment i.e. “how much software?” (output), but significantly a qualitative assessment i.e. “how valuable do we expect this software to be?” (impact and outcome). Contemporary Agile development techniques (continuous deployment etc.) mean that some organisations are able to release many times during Sprint and bring real usage data to Sprint Reviews. This makes Project Boards reviewing RAG reports relative to months (or years) old plans look incredibly outdated.

For an excellent recent article on assessing Impact and Outcome rather than Output, see ImpactMetrics by Hamlet Arable.

Question for leaders:

Given that Agile opens up the opportunity to inspect (and release) working increments of the product early and often, which measure of progress do you believe if focused on the right thing for your business?

1. Quantity of output, irrespective of how valuable that output is; or
2. Perceived future (or even realised) value of the output in terms of impact toward desired outcomes?

Organisation Design conflicts

Control hierarchy over “delivery” team scales up the bureaucratic control layer

PRINCE2 Agile defines a hierarchy above an “Agile product delivery team” including a Team manager (who may be seen as part of the delivery team) who reports to a Project Manager who reports to the Project Board. This establishes a three-level control hierarchy and takes the bureaucratic control layer of the organisation in the exact opposite direction that Scrum suggests – scaling it up rather than descaling it. For more on what Bureaucratic control is, see William G. Ouchi’s seminal paper A Conceptual Framework for the Design of Organizational Control Mechanisms (PDF).

For how Scrum can descale bureaucratic control, shifting it to market and clan control see slides 50-60 of Illuminating the Full Potential of Scrum by Comparing LeSS with SAFe.

Not designed for Agile performance characteristics

Systems Thinking helps us to see organisational systems as things that we can optimise toward certain performance characteristics. Whilst not explicitly stated anywhere that I’m aware of, I would suggest that PRINCE2 Agile’s management by exception approach can be seen as optimising for:

• short term projects (rather than long term product, “value streams” or total cost of ownership),
• robustness and perception of predictability (as distinct from actual predictability),
• perception of centralised management control through internal contracts (as distinct from actual control through collaboration),
• minimisation of stakeholder workload in projects (“bother me only when necessary” approach),
• individual accountability (as distinct from team/group accountability)
• flexibility of staffing of projects (e.g. with varied temporary contractors and vendors rather than long-lived stable teams)
• not creating the conditions for optimal team performance

Scrum, is designed to optimise for very different performance characteristics:

• resilience and high agility (adaptability),
• ability to work in customer value order,
• ability to release at least once per Sprint,
• short feedback loops for high learning and
• conditions for high team performance.

Question for leaders

1. Which of the above sets of performance characteristics do believe will best serve your organisation now and in the future?
2. Do you think that the downside risk of not having the above capability to meet future challenges outweighs the cost and difficulty of the change that may be required to achieve it?

If someone skilled in organisation design were to start from a fresh slate and design an organisational structure that supports this second set of characteristics, I would suggest that they would not design PRINCE2 Agile. Further more, even if your aim were to create “governance” oversight by senior people, this could be done without constraining Scrum such that the advantages of its potential performance characteristics are lost.

Adopting an organisation design created for one set of performance characteristics (top-down control) and then trying to get that design to have a different set of performance characteristics is a recipe for friction. It is not skilful organisation design.

A ScrumMaster would remove the core PRINCE2 management roles

I still have Ken Schwaber’s original Certified ScrumMaster slide deck authored in 2004. His slide introducing the ScrumMaster role starts…

“As a ScrumMaster, you are responsible for:

Removing the barriers between development and the customer so the customer directly drives development;”

Are there barriers between development and the customer defined in PRINCE2 Agile? Yes. The Project Manager is not the customer, nor is the Team Manager. Are they intermediaries between the person paying for the development and the responders doing the development? Yes.

I would contend that a ScrumMaster enacting the first responsibility of the role as originally articulated would work to disintermediate by removing the Project Manager and Team Manager roles from PRINCE2 Agile.

They might teach the business unit with biggest stake in the project what it means to have drive development directly through a role called “Product Owner”. This isn’t just a role about adjusting the order of a fixed set of backlog items and feeding them to the team. It’s commercial decision making role that enacts:

Customer collaboration over contract negotiation

A ScrumMaster might teach managers about how the Team Manger role conflicts with having a self-managing team by doing the managing for the team. Also how having an individual accountable for the work of a team diminishes the team’s shared responsibility as a team for what the team does. They might also discuss how being accountable for the work of others almost invariably leads to the accountable individual exerting control – typically in a command and control mode – over those that they are dependent on to fulfil their accountability.

Question for leaders:

Which do believe will be best for your organisation’s health and success:

1. Control through a competitive win-lose game of contract negotiation between business and development; or
2. Control through a co-operative win-win game whereby business stakeholders steer development directly, sharing the risk in a partnership with the development group?

Conflicting values

Whilst the values, and to a lesser extent the principles, behind PRINCE2 are not as explicit as with Agile and Scrum, when examined with an Agile or progressive management perspective, they are largely contradictory.

A thoughtful article that explores the discrepancy between the Agile vales + principles and the PRINCE2 approach is Can you combine Agile with Prince2 ®/ MSP? ® Or perhaps the question is, why on earth would you want to? 

Project vs Product friction

Conflicting use of project and product concepts

PRINCE2 Agile talks to an organisational context in which there are only “Projects” and “BAU”. It does not address the context of ongoing Product Development of customer centric products which is the context that Scrum is based on.

PRINCE2 Agile (and PRINCE2) guidance subordinates so-called “business products” to projects. When “project” is mentioned in the Scrum Guide, it is to say that “Each Sprint may be considered a project with no more than a one-month horizon.” Following the Scrum Guide here would tend to do away with a complicated project governance and management method like PRINCE2 altogether in preference for long-lived Product Management and Product Development.

Dismissive of ongoing product development

This underscores the two different worlds that PRINCE2 Agile tries to blend. In my experience, the project world could learn a lot from the product development world. The PRINCE2 Agile guidance dismisses long-lived product development as “BAU” and much simpler than projects. In a video introducing PRINCE2 Agile, primary author Keith Richards repeatedly expresses a dismissive attitude to working on organisationally non-trivial development efforts without projects. In doing so, the project community again deny the relevance of a product development community that has refined its craft for decades in competitive market situations that have a much higher success bar than most IT heavy business projects.

In my experience, focusing on the internal management abstraction of a project takes focus away from the experience of the end customer. The first principle of the Manifesto for Agile Software Development begins:

“Our highest priority is to satisfy the customer…”

Questions for leaders:

1. Which would you rather have your people focus on each day?:
   a) finishing the project to satisfy an internal contract or
   b) satisfying (and potentially delighting) the end customer?
2. Have you studied customer-centric alternatives to using projects?

There are now books that directly address this transition:

• #noprojects: A Culture of Continuous Value by Evan Leybourn and Shane Hastie
• Project Myopia: Why projects damage software #NoProjects by Allan Kelly

in addition to the many books on long-live Agile and Lean product development. A good example is Large-Scale Scrum: More with LeSS  for which the introductory chapter is freely available online.

Accomodating Agile adoption rather than improving it

Compensating for and holding back Agile maturity

The PRINCE2 Agile manual largely reads like a guide to enable Project Managers encountering a degree of Agile practice to navigate how they operate in that environment. Also to tailor how heavy the application of PRINCE2 is depending on the maturity of the Agile implementation. Without a goal of putting concerted effort into improving that Agile capability or supporting a ScrumMaster in doing so, the PRINCE2 and traditional project management mechanisms are to be imposed more heavily. In many cases, I would expect this to result in it being more difficult (not less) to increase the maturity of the Agile adoption.

What I see in practice is that if there continues to be a Project Manager role, stakeholders expect the individual in that role to be accountable for the success of the project and be “in control” of the project to those ends.

The goal of the PRINCE2-style Project Manager to control the project themselves clashes with the goal in Scrum of a ScrumMaster to enable control to exercised by Product Owner and Development Team in an environment of high customer engagement and transparency.

What PRINCE2 Agile does not address is leadership in capability building. Perhaps the assumption is that one or more ScrumMasters are sufficient to achieve this. Many may be surprised as to what a ScrumMaster may work at changing about the PRINCE2 Agile implementation in order to fulfil their responsibilities.

Conclusion

The question that I posed at the start of this series was:

can you actually have both PRINCE2 and Agile integrated without having one irreconcilably compromise the other?

If PRINCE2 Agile is the best attempt that we have at combining PRINCE2 with Agile then the answer is: No. Not without Agile being so constrained as to be limited to little more than incremental development with new terminology. Agile in name only perhaps.

By retaining the full PRINCE2 structures including roles and processes, the alternative structures and interactions of Scrum and other Agile methods are prevented from being used to serve the intended ends. By retaining positional authority and control up a three level PRINCE2 hierarchy, the Scrum Team – particularly Product Owner – are prevents from having the authority that Scrum calls for.

The many conflicts between PRINCE2 and Agile (particularly Scrum) that PRINCE2 Agile highlights indicates that PRINCE2 and genuine Agile blends like oil blends with water. The exception may be that you believe that it is reasonable to call it “Agile” when taking only select delivery practices from the Agile camp without respecting the implications for governance, project or product management, discovery, organisation design and mindset.

If you really do want Agile in a way that allows Scrum to be implemented effectively. In a way that gives you a shot at achieving agility, higher customer value, increased learning and/or team performance then PRINCE2 Agile is not a recipe for that.

Leaders would do well to understand that PRINCE2 and Agile are built on substantially different management philosophies and to achieve substantially different organisational characteristics. Also that attempts to “blend” them are inevitably going to be compromising one. Or compromise both, with the potential for a “worst of both worlds” outcome.

The latter is neither robust nor resilient and neither exploiting control culture or collaborate/create culture. As I have seen many times, heavily constrained “faux” Agile leads to friction and frustration. Leaders should look carefully for weak signals of this and work to create coherence, not dissonance between conflicting approaches.