Princely agile

Whether running an agile project or a Prince 2 project, the principles at work are the same, in both cases a project is broken up into small pieces and regular formal inspection is applied to ensure alignment. It is in the detail of the how & why of that decomposition, and the interpretation & exercise of control, that important differences can be found. Another important difference is the level of prescription, Prince 2 attempts to describe the complete set of possible project contexts and states that the method should be pared to fit. Agile methods, like scrum, tend to prescribe very little and insist that context will determine how the method or framework should be extended for any given situation.

Ironically enough the majority of so-called Prince 2 projects are PINO (prince in name only), have few or no (non-project management) products defined and never include stages (which should not be confused with phases), nor the associated formal decision moments on how to proceed, or not. This means that stopping a project often only becomes an option when original deadlines and/or budgets have been thoroughly and spectacularly violated, more often than not without the delivery of any usable product whatsoever. The PID (project initiation document) often remains live deep into the project lifecycle, sometimes being finalised only when the project draws to a close (talk about gaming the numbers!).

Product based planning is a cornerstone of Prince2 and, if applied appropriately, can provide a link to agile methodologies. Appropriate application would involve hi-level specification of products during the Initiation phase, whereafter detail is added incrementally and iteratively, just-in-time and through collaboration with the team. Minimum viable product (or feature) should be the guiding principle in designing a product breakdown structure (PBS) - not process flow like requirements document, analysis document etc.

But if scrum is a framework for project management, why would you need Prince 2 at all?

Well, scrum is indeed sparsely prescriptive and basically says nothing about (financial) governance other than that it is up to the Product Owner. In fact the role of Product Owner is one of the most problematic aspects of scrum. Scrum says that the PO should have vision & authority and be (always) available to the team thereby ensuring maximum value delivery. This is a difficult assignment, and if the stakeholder and/or user landscape is complex enough, it requires nearly superhuman abilities to execute satisfactorily. A sparse version of Prince 2 could provide a solution here. Specifically, a steeringboard could provide a workable escalation channel in priority disputes (as long as it is still employed according to the principle of management by exception, i.e. at the discretion of the PO), and the maintenance of a formal business case might provide an explicit policy for the PO to work from from day to day.

I have used Gojko Adzic's (most excellent!) Specification by Example to create a mapping between Prince 2 phases (always mandatory != stages) and agile execution:

Project Start

• State goals (Brief/Mandate)
• Appoint Steering Board
• Appoint Project Manager or PO
• Assign existing team(s) to the project

Project Initiation

• Collaboratively determine scope (hi-level PBS e.g. in the form of Story Mapping/Initial creation of Product Backlog, consisting necessarily of primarily rough-grained stories)
• Create business case
• Collaboratively elucidate hi-level risks

An initiation phase could easily consist of a small number of sprints, this would ensure a much better understanding of scope & risk, and allow for using actual velocity in provisional (release) planning etc

Project Execution

• Managing stages & stage boundaries: Each iteration is closed with the demonstration of working software, actual progress is tangible and concrete which means that the validity of the business case can be continually reviewed and assessed with confidence. The definition of formal stages to this end may be overkill.
• Work package creation & acceptance (and associated wasteful hand-offs) are replaced by the ongoing collaborative activities of backlog grooming (“refining the specification”) & sprint planning. A project manager (if there is one) therefore has no role in activity planning.

Closing a project

• Lessons learned – continually generated during the project (review & retrospective)
• Product handover – not necessarily applicable if every sprint realises (potentially) shippable product
• Review goals

Et voila – princely scrum!

Of course, there are those who suggest that management generally (Radical Management, Management 3.0) and financial governance specifically (Beyond Budgeting) would also benefit hugely from an agile approach. I agree, princely scrum (if and when contextually appropriate) should be but a step on the road to imperious agility.