Using PRINCE2 Principles to Govern Agile

I wrote recently about the differences between waterfall and agile, and how agile can be a solution but presents its own challenges – you can read about it here: The secret to managing risks well in agile environments.

The purpose of that post was to communicate that agile isn’t – or at least shouldn’t be – a wild west of uncontrolled change for people who don’t like documents. When it’s done well, it can manage risks better than waterfall does, but that’s not very helpful when you’re trying to design (and then govern) an effective change function.

Agile practitioners tend to dislike being held to ransom by a methodology, and PRINCE2 is probably the most dreaded of the lot. But I’d like to suggest that when one takes the principles of PRINCE2 rather than its (over?) engineered management practices, it’s possible to manage change in an agile way without losing the comfort that well-designed control brings.

So let’s explore the seven PRINCE2 principles and see how they can be applied to agile environments.

Continued Business Justification

PRINCE2 says that every change initiative should be able to demonstrate its value to the organisation, and that’s core to agile as well. Every user story states what value it will deliver, and showcases and retrospectives give great opportunities to revisit that value.

Learn from Experience

The medium PRINCE2 chooses to capture ways to improve approaches to change is the Lessons Learned Log, which is a pleasing alliteration but runs the risk of sitting in a virtual filing cabinet and therefore doesn’t really deserve its title as having recorded lessons learned.

Agile relies on retrospectives, which are frequent and public, and therefore this principle is already embedded.

Defined Roles and Responsibilities

The calling card of an agile environment is the information radiator, boasting sticky notes and avatars that are moved around the board on a daily basis. Roles and responsibilities aren’t written up into detailed job descriptions, but they’re public and are revisited regularly.

Manage by Stages

The purpose of this principle within PRINCE2 is that senior management have clearly defined expectations and are informed of progress on a defined basis to allow for decisions around how to move forward to be made in a timely manner.

Agile fully embraces this one as well, typically inviting senior management to showcases on a fortnightly basis and reporting regularly on an agreed cycle alongside that. The frequency may be greater than PRINCE2 typically expects, but this principle is definitely there in agile.

Manage by Exception

The purpose of this principle within PRINCE2 is to avoid filling senior management time with ‘busy work’, defining tolerances within which the next layer of the hierarchy is allowd to operate autonomously.

Agile approaches this slightly differently, but the practice is still there. Product owners form a core part of the team, and are empowered to make those big decisions, and the daily standups and identification of blockers form an efficient way to raise exceptions and address them directly.

Focus on Products

For all its apparently mandated project management documentation, PRINCE2 is upfront about the fact that projects exist to deliver change rather than audit artefacts.

Agile fully agrees with this too; a foundation of the Agile Manifesto is to value working software over comprehensive documentation – a line that could have been lifted straight out of the PRINCE2 textbook.

Tailor to Suit the Project Environment

The purpose of this principle is to select the right level of PRINCE2 controls for the environment. A mandatory regulatory-driven change that costs £30,000 needs less of a business case than a £80m transformational change. And this sits very comfortably within an agile environment; where documentation isn’t justified, it shouldn’t exist.

What just happened?

A relatively simple exercise to review PRINCE2 from an agile perspective, and it feels like the two approaches are far more closely aligned from a principles perspective than one would have expected.

Is it possible to run a change initiative in such a way that agile purists and PRINCE2 purists will both be happy? The answer, as we’ve just seen, has to be a resounding “yes!” but…semantics and preconceptions can be tricky things to overcome, so it’s unlikely to be an easy ride in the short term.

All in all, when it’s done well, agile offers unique value. In many cases it can be better at managing risk than waterfall approaches, and that requires an intelligent, mature approach and a willingness to concede that there are perhaps better ways of working.

Arrange a Conversation