PRINCE2 Agile

“Watch this space”– there’s a new qualification emerging from the AXELOS Best Practice stable!  ‘PRINCE2 Agile’ is imminent, currently estimated for release end Qtr1 2015.  PRINCE2® Practitioner will be a pre-requisite to obtaining the qualification and, as it’s still in development, the specific details of how PRINCE2 Agile will be tested are unclear.

For the un-initiated:

PRINCE2 is about managing projects in a controlled way.  Even the term PRINCE2 itself stands for ‘PRojects In Controlled Environments’.  It’s about top-down management and tight control, especially of any proposed changes to project scope / requirements.  PRINCE2 entails having a clear understanding of the project business case, comprehensive project documentation with detailed, signed-off requirements, clearly defined accountability and responsibilities and high level decision making.  PRINCE2 is not industry specific and can be used to direct and manage a project of any size or complexity.  ‘Die hard’ PRINCE2 practitioners, especially those who have managed very large scale projects, tend to be highly suspicious of agile methods, believing it puts ‘developers in charge’ and does away with project management controls, making the project impossible to plan or cost.  In fact what is the role of a project manager on an agile project and perhaps Agile should only be applied to small, low risk projects?

AGILE is a term used (in the IT Industry) to describe a broad collection of different methods / approaches, such as ‘Kanban’ and ‘Scrum’.  It came about to try to improve the ability of IT projects to respond to, even welcome, changing requirements.  Agile methods advocate self organising, empowered teams who develop software in frequent, short time-boxed iterations with only high level requirements agreed up front and lower level requirements emerging through the iterations.  There is a focus on delivering working software rather than documenting the project / requirements.  Customers / users are involved with the development team in usually daily (ideally face to face) meetings to share progress and discuss problems.  Although the Agile manifesto only emerged in 2001 it has become extremely popular and is now hard to ignore.  Some early Agile adopters tried to ‘sell’ Agile as a panacea for all projects, and through empowerment the team will be highly motivated and therefore the benefits of self-organisation outweigh not having the rigours of traditional project management.

So, at first glance, combining the terms ‘PRINCE2’ and Agile in the same sentence might seem like a paradox.  An ugly, even impossible, alliance if you will.  Are AXELOS trying to combine chalk and cheese here?
I don’t think so, and I’ll briefly try to explain why.

Firstly, it’s a question of extremes, or rather lack of.  A project that is ‘heavy’ on badly implemented PRINCE2 could drown in too much paperwork and bureaucracy.  But PRINCE2 itself says don’t do this, rather tailor the method to suit the specific project and use a ‘lightness of touch’.  At the other end of the scale ‘extreme Agile’ could be interpreted to mean that project managers are ‘just’ facilitators, and that projects require little or no project management control, but Agile seems to have matured since the heady days of early adoption.

Next, embedded within PRINCE2 are the concepts of tolerances and management by exception.  Put simply, tolerances are any lee-way that is acceptable around various project targets, and can be set for timescales, costs, (product) quality, scope (what’s included), benefits and risk.  Another way of explaining tolerances is as ‘limits of delegated authority’, and different limits of authority can be set for the different levels of management on a project.  The most common elements of tolerances are for time and cost, but Agile really exploits the concept of scope tolerance.  One technique for handling scope tolerance, which is even explained in the PRINCE2 manual, is something called ‘MOSCOW’, under which your products (deliverables) are categorised as follows:

• Must Have
• Should Have
• Could Have
• Would Like

If products are thus categorised before a stage of the project (PRINCE2) or ‘sprint’ (Agile) starts, the project team knows where the line is, and what can be ‘legally‘ dropped.  On an Agile project the date(s) of iterations (delivery slots / sprints) are absolutely set (i.e. there is no time tolerance), and the project will de-scope as necessary to make sure the dates are hit.

Let’s now explore potential differences around requirement specification.  PRINCE2 states that high level requirements are detailed up front in something called a ‘Project Product Description’ and the lower level requirements are detailed in lower level ‘Product Descriptions’ which are documented / signed off closer to the time (project stage) when the products will actually be created.  Agile methods also advocate only having high level requirements agreed up front. The project then works from a list of requirements (may be called a ‘Project Backlog) and the very detailed requirements evolve during the detailed collaborative work of the team(s).  So, we have a slight difference here in that with agile the team contribute to developing the very detailed requirements as they go along rather than being given them before they start development of those products (PRINCE2).  For me it’s partly a question of ‘how detailed’ should requirements be up front?  This is a perennial problem on most projects.  It is often only when the team gets right into the ‘nitty-gritty’of requirement gathering some issues and escalating costs emerge.  Furthermore, judgement and experience is required to decide when something is a true change / additional requirement (in PRINCE2 this is called a Change Request) or when is it just a refinement of understanding / a requirement evolving?  This of course is the source of many disputes with suppliers, especially when requirements are unclear.  Does it come back to the team(s) knowing their boundaries for decision making (tolerances)?

Perhaps PRINCE2 and Agile are not such uncomfortable bed-fellows.  Maybe this marriage of ideas could be a good thing with PRINCE2 acting as a wrapper that sits around / above teams working in a Agile, collaborative ways, given clear boundaries for stages / work packages / sprints – call them what you will.  Maybe this marriage isn’t so new / radical, and it is just that some fresh guidance is required to help them sit comfortably together and minimise risks that Agile on a large project could introduce?  I don’t believe that Agile advocates suspending common sense, and not having a good handle on your business case and costs.  It was always intended to be pragmatic without abandoning quality.

Practical questions do still remain for me, and here are just some of them:

• How to keep a good handle on costs when teams self-organise and change rules the day?  Perhaps this is achieved by rigorous application of cost tolerance?
• Can you ever realistically give a fixed price for a large scale Agile project?
• Surely the risks and cost will increase when changes are not contained? Surely this makes it harder to weight up the business case until quite a way into the project?
• How Agile can be practically scaled up for larger projects to cope with multi-disciplinary teams and cross dependencies?
• What should the escalation routes be for different types of exceptions / issues.  Perhaps PRINCE2 already caters for this with changes going to a designated ‘Change Authority’ (Agile – ‘Product Owner’) which is a different route from escalating a forecast threat to tolerance
• As Agile has grown out of IT projects and PRINCE2 Agile is intended for any industry, will it really work in those other industries?

Whilst we could all apply our own thoughts and solutions to these matters it would be nice to have case studies and ‘best practice’ guidance to help us through.  I hope the new qualification will fill this gap.
While we wait for the qualification, let’s keep in mind that extremists in most philosophies and concepts are often dangerous and should be treated with caution!