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.
Both approaches provide mechanisms to avoid common project pitfalls and significant risk-reduction can be realized by understanding the underlying principles of both and implementing a combined process. The majority of arguments against the combination of agile and PRINCE2 come from the agile community, the broad argument being that that PRINCE2 is overly prescriptive and heavyweight. There are undoubtedly implementations of PRINCE2 that fit this description, but it is worth revisiting the seven defined principles of the framework:
- Continued business justification
- Manage by exception
- Learn from experience
- Defined roles and responsibilities
- Manage by stages
- Focus on products
- Tailor to suit the project environment
Some of these are directly aligned to agile principles, such as continued business justification, learn from experience and tailoring for the specific project. And there are some considered reasonable though not completely in alignment with agile, such as manage by stages and focus on products.
The major problem for many agile practitioners, however, is managing by exception.
Managing By Exception
The most efficient form of providing useful information to stakeholders and other interested parties is by exception. This involves establishing a clear, agreed baseline then reporting when the baseline changes or is at risk.
The starting point for Managing by Exception is, therefore, a well-defined outcome. For example, we will have delivered X by date Y. As the project progresses either the same outcome is still being forecast, i.e. no exception, or there is variation of the planned outcome and an exception is raised. The concept of well-defined outcomes in turn leads to baselines and from there to the controlled management of change to those baselines.
Baselines and change control are absolutely not part of standard agile. The reality is that baselines and change management still exist on even the most agile of projects, although they are normally implicit. Even if the solution being built is highly variable, the problem to be solved – the “value proposition” – is still the same. There is always a question of what is sacrosanct and what is not.
The question is not whether there is a baseline but at what level of detail the baseline should be defined. The benefits and risks of an agile approach can hinge on how well the baseline is understood, communicated and agreed by all parties and whether stakeholder expectations are kept aligned with the solution being delivered as the project progresses. It is possible to define a baseline within agile that provides mechanism for reporting, whilst remaining responsive to user needs. In addition to the backlog, this will comprise: value proposition, incremental plan and plan for the explicit management of uncertainties.
Managing in Stages
Once the baseline is established, PRINCE2 advocates “Managing in Stages”, where the Initiation stage is followed by clearly defined formal review points in which the project is reassessed in terms of its original intent.
A traditional project has easily defined review points built into the process itself. Because the entire project approach is based on ongoing refinement to the next level of detail, the outcomes (including all of scope, time, cost and risk) can be reassessed at each milestone based on the new level of understanding. An agile project however is relatively homogeneous after initiation. It is possible that the Release Plan provides specific points where the original proposition can be reviewed at useful intervals, but this is not always the case. Some projects release continuously, while others might only release at the very end.
To achieve the objective of PRINCE2 is in fact very easy here: it is simply a matter of planning in major review points after appropriate events or periods of time. This can be after a release or at the end of any specific sprint.
Roles and Responsibilities
In addition to the process of creating a baseline and reporting by exception, PRINCE2 calls for clearly defined roles and responsibilities. In contrast, agile seeks to minimise the use of defined roles and work collaboratively toward collective goals. It is, however, possible to differentiate between team roles (where collective ownership is important) and governance roles (where clear individual responsibility is important). This is a key area in Agile and is made explicit in PRINCE2 Agile.
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 baseline plan is critical to this; once defined this provides the mechanism for management and governance within a formal structure.
See our PRINCE2 Agile section for more information.
Have you found agile methods useful when managing projects using PRINCE2 or other methodologies? What aspects of each have you found to be compatible and what techniques have not been complementary? Please share your thoughts and experiences in the comments box below.