Insight Agile with PRINCE2

This paper presents IndigoBlue’s approach to integrating Agile with PRINCE2®. It explains why the two approaches can be used together at a conceptual level, and follows with a discussion of the key differences and how they can be resolved. This paper assumes that the reader has a prior level of knowledge of the two approaches.

It is often supposed that Agile and PRINCE2 conflict directly with each other, and cannot be used effectively together. The basis of this view is that PRINCE2 is ‘process-heavy’, while Agile is ‘process-light’.

In reality, both processes are highly configurable, and PRINCE2 can certainly be implemented in an acceptably light form. It should also be noted that PRINCE2 is a generic process, intended to cover a wide range of different project types, and should therefore be able to accommodate an Agile implementation approach.

Both approaches provide mechanisms to avoid common project pitfalls, and significant risk-reduction can be realised by understanding the underlying principles of both and implementing a combined process. IndigoBlue’s standard process is based on this view, derived from our in-depth experience of both traditional and Agile processes.

Key Concepts

In broad terms, PRINCE2 and Agile are focused on different objectives.

• PRINCE2 is an approach to project governance. Its aim is to ensure effective project control, meaning that decisions are be made by the right people, at the right time, based on accurate information.
• Agile is an approach to achieving higher quality end products through the use of review and feedback.

There is nothing about these two aims which should be incompatible. If an Agile process were to inherently reduce the level of viable governance control then at worst it would be a flawed process, and at best would be usable only in limited situations.

There are however risks inherent in the way that each process can be implemented in practice.

Implementation Challenges

Agile initially became popular through adoption by the development community. Many implementations of Agile are therefore ‘developer centric’, with a reduction in focus on project governance considerations. The success of these projects can lead to a view that introducing governance overheads is counter-productive.

Clearly this is not the case. A process can be successful when employed by individuals who are interested in state-of-the-art techniques and motivated to make them work, but might not work with other individuals who are not so skilled or motivated. Appropriate visibility will enable management to determine whether the specific combination of project, team, and process is working.

Agile development emphasises delivery of high-quality product (as against interim documentation), which is one of reasons it can be so successful.  However, a principle that can get lost is that a team is also responsible for generating information that enables appropriate decision-making at a higher level.

PRINCE2 implementations, on the other hand, can suffer from being activity and artefact driven, rather than objective driven. This is not the intent of the PRINCE2 methodology, which provides process items to consider in context, rather than blanket, mandatory solutions. An example might be a mandate that every project has a plan in Gantt-chart form (discussed below), rather than that every project has a well-defined and well-considered plan.

This is often done to make the Project Assurance task easier through consistency of Management Products. However, the fact that a current PRINCE2-compliant standard in an organisation does not cater for an approach such as Agile is not an argument that PRINCE2 itself does not. It means that the standards need to be enhanced.

The Bigger Picture

The most common use of the Agile process is for software development, notwithstanding that many other types of project can benefit from the approach.

While some projects are scoped to include only the software development itself, in the general case software is only one aspect of a wider project, which will include, for example: infrastructure changes, operational changes etc. Whether these other activities are considered as part of the same project or not, there is a still a requirement for overall management of all activities.

PRINCE2, as a generic project process, will address the whole set of activities. The detailed process for each activity may be different: for practical reasons, or simply because the optimal process is always dependent upon the task, people, and environment.

This scenario leads to two key process requirements:

• The implementation of PRINCE2 in an organisation must be able to accommodate varying process at the detailed level.
• Agile must be able to integrate effectively into a wider project process.

Differences in Approach

This section discusses some of the key differences of approach between PRINCE2 and Agile and identifies how these differences can be resolved.

Incremental Delivery

Both PRINCE2 and Agile promote the concept of dividing up a project into a serious of distinct delivery points.

PRINCE2 has the concept of a Stage, which is a governance point where the Project Board decides to go ahead with the next phase of work. The more Stages a project has the more opportunity there is for feedback and steering. This is offset by an additional cost overhead in adding extra Stages, due partly to more frequent meetings of the Project Board, but more significantly by the cost of closing down a deliverable in one stage and reopening it in the next.

Agile goes further in this line of argument than PRINCE2. It asserts that the quality of the end product is significantly increased through ‘continuous’ feedback and steering. It also asserts that the optimal plan is one where the final solution is arrived in a series of increments, where each increment is complete in itself and adds additional business value. Other aspects of the Agile process are set up to support this, by reducing the cost overhead of closing down and re-opening deliverables, and accommodating the level of change which inherently results from feedback.

There is therefore no inconsistency between the two approaches. Agile adds to PRINCE2 in that:

• It enhances the options available when selecting Stages during project planning, by reducing the cost overhead of Stages.
• It places a requirement on the definition of Stages, that each Stage should provide incremental business value.

The unit of arriving at a checkpoint for delivery and feedback on an Agile project is an Iteration, which is time-boxed and of short duration (1 to 4 weeks). One question which frequently arises is whether an Iteration is equivalent to a PRINCE2 Stage?

The simple answer is that they are not equivalent. An Iteration is not a governance checkpoint – it is a device used by the implementation team to enforce frequent closure. In general Agile terms, a Stage is more likely to relate to a Release, where the results from multiple Iterations are put live. Even that may not be case, as projects can release every iteration.

IndigoBlue’s Agile process introduces the concept of a Functional Milestone, being the point where the functionality to achieve a clear business aim has been produced. This is a good candidate for a PRINCE2 Stage, although it is still possible to include multiple functional milestones in a single Stage

Project Start-up

PRINCE2 has a number of critical activities and checkpoints that occur during the start-up phase. Unsurprisingly, every Agile process also has specific start-up activities (although they do not all have well-defined checkpoints).

The PRINCE2 checkpoints are used to decide whether to go ahead with the project. This can be divided into two decision points – the first decides whether to invest the effort in exploring the project further. Clearly, whether it is part of a defined process or not, some mechanism must be used to make an investment decision, so this is not in itself a difference between the two approaches.

PRINCE2 only requires that sufficient information is available at the key decision points to make an informed decision. An Agile implementation should provide that sufficiency regardless of whether PRINCE2 is being used. IndigoBlue incorporates this into its standard Agile project initiation process.

The Agile approach adds some additional considerations to the project start-up activity:

• The definition of ‘sufficient’ is examined more closely. If a first-pass estimate of a project is £100k cost against £500k benefit then that first-pass could be deemed sufficient: the go-ahead decision is easy. If the decision is more borderline then more detailed up-front clarification may be required.
• An Agile approach can carry more uncertainty. This is possible because the process focuses more effort on being responsive to unfolding events than on accurate advance predictions. This enables, for example, analysis to be performed in parallel with development, thus reducing the up-front period where no business value is being delivered. If a project has too much uncertainty though (e.g. functional, architectural, or estimates) then it is carrying too much risk. The governance decision process has to include an assessment of the level of uncertainty.
• A traditional start-up process needs to look at what is required and estimate the cost of delivery of this as a totality. An Agile approach seeks to deliver incrementally and in order of decreasing business benefit. This requires that the business goals are more clearly understood and are factored directly in an Incremental Strategy (an IndigoBlue concept) and the prioritisation.
• Whatever approach is used to generate the initial costing, the mechanism does not inappropriately constrain the resultant project. This is because closing down on a solution too early in a project actually increases the project risk, i.e. the risk that the solution is not optimal, or worse, is not fit-for-purpose.

Planning

One of the project start-up activities is to produce a project plan. Agile processes are no exception to this, but the form of plan is different from a traditional project.

In PRINCE2 a plan (in broad terms) is a list of Products, a list of activities to achieve those Products with estimates, dependencies between the activities, identification of the resources required and available, and the mapping of resources to activities. This is then aggregated to provide and overall cost and timescale. The standard tool for expressing such a plan is the Gantt chart.

On an Agile project the plan is effectively the Product Backlog or Feature List: a linear, prioritised list of deliverable units of end-product where ideally each adds new business value. It is inherent in this form of plan that dependency considerations are minimal (specific Agile techniques are focused on making this statement true) and that the team as whole is assigned to tasks, not individuals.

A Gantt chart is totally inappropriate to this type of plan, providing no useful information not already available in a simple list. Gantt charts are not however mandated by PRINCE2. It should be noted that where the characteristics of a project move away from the ideal that can be expressed with an Agile plan, then it is possible to combine the two approaches to create the most expressive model.

Another feature of an Agile plan is that it continuously refined throughout the project. The implications of this are covered under the section on Change Control.

Configuration Management and Change Control

Configuration Management (defining baselines of Products), and subsequent change control, is the area where the PRINCE2 and Agile approaches have maximum potential for conflict.

The cause of this conflict is that the Agile approach, which includes carrying uncertainty and promoting review and feedback to arrive at an optimal solution, inherently creates significant amounts of change. The approach also acknowledges that the context typically changes during the course of a project, and is set up to accommodate that change.

At the same time it is clear that projects need to control change to avoid ‘scope creep’, the key issue that the PRINCE2 change control mechanism are designed to address.

The solution to this apparent contradiction lies in two areas:

• Deciding what is maintained under Configuration Management (this decision is a standard part of the PRINCE2 start-up process)
• Use of PRINCE2 Tolerances to give the project a well-defined mechanism for being able to handle change effectively on a day-to-day basis while still giving the Project Board the necessary level of control.

A traditional implementation of PRINCE2 will normally identify the detailed solution as a key baselined artefact. An Agile approach will seek to allow the solution to ‘emerge’ during the course of the project. If the solution is intentionally non-definitive then it becomes more important that the project vision and objectives, and any high-level strategies, are clearly stated, and these should be managed under change control.

There is also no reason why the solution itself cannot be documented and maintained under change control, but it needs to be recognised that the purpose of this document is not to drive the implementation, but to achieve other objectives that should be identified by the Project Board. The level of detail in such a document will be different from an equivalent document on a traditional project, as the working software itself can be used as part of the communication of the solution. If the level of detail is too great then the document will become an impediment to change, and thus to achieving the optimal solution.

The Product Backlog should be under configuration management. It constitutes a formally agreed plan, and some changes to it will have a direct impact on the outcome of the project.

These changes might be changes in estimates, the inclusion of new features, or the removal of features. Equally though, if the change control procedures are too onerous they will inhibit desirable change – which is recognised by PRINCE2 in the setting of Tolerances.

The standard PRINCE2 categories for defining Tolerances are: time, cost, scope, risk, business benefits, and quality.

The categories that Agile projects need a specific strategy for are Scope and Business Benefit, being inherently inter-related. Some typical approaches used within the IndigoBlue Agile implementation are Tolerance levels:

• where changes to the Product Backlog have to be agreed before the Product Backlog is updated
• where the Product Backlog can be updated directly, but changes should be reported as part of normal exception reporting, and reviewed by the Project Board
• provided to the delivery team for changes to estimates which need to be agreed with the Project Manager.

Project Sponsorship

PRINCE2 identifies the Project Board as an essential part of the project organisation, providing clear leadership, vision, and authority for decision making and issue resolution.

The Agile approach also requires engagement with ‘owners’ for the same reasons.

Where the approaches differ is that Agile requires a more continual engagement than can normally be facilitated through a PRINCE2 board. If the board members have the authority and strategic view that is required to fulfil their function then they are unlikely to be able to dedicate the time required by an Agile project.

In practice the PRINCE2 approach provides an excellent solution to a problem often experienced by Agile projects: getting the right level of engagement with business representatives. PRINCE2 defines the Senior User’s role on the Project Board as ensuring the fitness-for-purpose of the solution, and identifying who needs to be engaged with, and how, and ensuring those people have appropriate time allocated.

The Agile approach provides specific options for how this engagement can take place with optimal effectiveness.

One concern with user representation, whether using an Agile approach or not, is that it effectively creates multiple delegation routes between the project and the board: the normal one through the project manager, and a second one through the user representatives. There is a potential for the user representatives’ goals or actions to be counter-productive to the project manager’s remit. This concern is exacerbated on an Agile project where the user representatives have a much greater impact on the on-going conduct of the project.

It becomes particularly important therefore that the Project Board creates a clear vision and that all parties are working as a single team towards the same goal. Ideally therefore the user representatives should become part of the delivery team and report through the project manager. If there is an issue that the project’s agreed direction is (potentially) not going achieve the business benefits then the project manager should own and be addressing this risk, and escalating it to the Project Board.

The user representatives should however have a clear remit from the Project Board, with boundaries of authority, and lines of communication to get rapid answers to issues or questions that lie outside these boundaries.

Conclusion

The aims of PRINCE2 and Agile are compatible and indeed, implemented appropriately, PRINCE2 can provide a valuable framework in which to govern and control Agile projects within a wider change programme.

The challenge is to understand and adapt the processes in order to address the underlying objectives of the approach.

---

PRINCE2 is a registered trade mark of the Cabinet Office.