And yes, that is a question! In fact, here is another question:
“Where in the PRINCE2 manual does it stipulate a traditional (waterfall) way to deliver projects?”
So is PRINCE2 that alien to an Agile approach?
Well, let’s have a look at the seven core principles of PRINCE2
- Continued business justification,
- Learn from experience,
- Defined roles and responsibilities,
- Manage by stages,
- Manage by exception,
- Focus on products,
- Tailor to suit the project environment.
I would suggest none of these are incompatible with Agile but let’s have a look at each of them in turn.
Continued business justification
The Business Case is an important document, and is updated at every Stage of the project to ensure that the project is still viable. Early termination can occur if this ceases to be the case.
This is completely aligned in terms of mindset – fail fast – or as I prefer: learn fast! All business cases should be short and data driven, period. How do we achieve this? We create a hypothesis that needs to be validated – a Business Model Canvas is an alternative way to express such a hypothesis.
Learn from experience
Each project maintains a Lessons Log and projects should continually refer to their own and to previous and concurrent projects' Lessons Logs to avoid reinventing wheels.
One of the over-riding cultures of an agile team is becoming a learning team (kaizen). Retrospectives are key; the Retrospective is an opportunity for the team to inspect itself and create a plan for improvements to be enacted during the next Sprint, appropriately prioritised. In addition, agile activity promotes ‘Community of Practices’ across teams and disciplines to cultivate sharing.
Defined roles and responsibilities
Roles are separated from individuals, who may take on multiple roles. By naming and defining roles in the PRINCE2 standard it becomes clear exactly who has what responsibility and decision making powers, hence avoiding arguments. Roles in PRINCE2 are structured in four levels (Corporate or Programme Management, Project Board, Project Manager level and Team level).
Agile is no different, it also defines roles, for example Scrum has roles, three of them in fact. DSDM has roles, more than Scrum I grant you that. Even Kanban recognises roles albeit by initially respecting existing roles, responsibilities and job titles.
Manage by stages
The project is planned and controlled on a stage-by-stage basis. This includes updating the Business Case, overall plan, and detailed next-stage plan after each stage in the light of new evidence.
For Stages read Releases in Agile (which may involve many Sprints) and Work Packages being a Sprint for one specific team. New evidence - surely there is not now an empirical process in PRINCE2?
Manage by exception
This is all about providing for the "efficient use of senior management time as it reduces senior managers' time burden without removing their control by ensuring decisions are made at the right level in the organization". Personally, I like to think of it this way:
- It's about setting Tolerances for people to work within.
- Getting regular reports (Checkpoints from Team to Project Manager; Highlights from Project Manager to Board) to know how things are going.
- Having a change control procedure to deal with issues when they arise.
- Not assuming that all this is always being done, so having some Project Assurance to check that the right things are being done in the right way at the right time by the right people!
In an Agile approach, the team need to understand their boundaries but within these boundaries they self-organise and are empowered to deliver i.e. we centralise strategy but decentralise execution. However, a team needs to be proactive when monitoring and controlling progress and to be able to prove they are in control. In order to fulfill this principle, an Agile team will:
- Use an appropriate level of formality for tracking and reporting.
- Make plans and progress visible to all.
- Make use of Daily Reviews to synchronise the team and raise impediments, risks and issues, which can be escalated, if required.
- Measure progress through focus on delivery of products rather than completed activities.
Moreover, the level of quality to be delivered should be agreed at the start and ensure that quality does not become a variable.
Focus on products
Each work package is defined by one or more deliverable products, preferably with tolerances to time and quality quantified in advance. This allows all parties to clearly specify what is required, and to allocate responsibility for delivering and controlling it.
Straight from the Scrum Guide, “The Sprint Goal is an objective set for the Sprint ……The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created…. . The definition of “Done” for the Scrum Team is used to assess when work is complete on the product Increment”.
So we have a focus (a goal) and a team commitment to that focus which needs to be delivered in time quantified in advance (a sprint) and with a definition of quality (done). Or am I missing something?
Tailor to suit the project environment
PRINCE2 should not be applied blindly in a dogmatic, bureaucratic form. This would lead to wasted time on paperwork and create false senses of security. Rather it is defined to be a method in need of tailoring to specific projects. A typical criticism of PRINCE2 is that the deliverable structure can lead to focus on producing deliverables for their own sake, to "tick the boxes" rather than do more useful work. If this is occurring, it demonstrates a failure of management to apply PRINCE2 and tailoring correctly.
An example of a typical adjustment is the replacement of deliverable reports and project documents by informal (verbal or email) equivalents e.g. Sprint Review, a Big Visual Chart. You mean to say that PRINCE2 actually supports such agile tailoring? Yep, it sure does!
My first Agile transformation was using DSDM as the delivery model, XP as the underlying engineering practices and PRINCE2 as the overarching governance model in an agile world. Here’s my first ever Agile Operating Model from 2005!
Image courtesy: Personal archive
So my question remains, is PRINCE2 really mutually exclusive to agile and if it is, why?
Please share your thoughts in the comment box below.
Find out more about the PRINCE2 course!