PRINCE2 Agile 2016
Previous Section   Next Section

6.4 The five targets in more detail

As previously mentioned, it is very important to understand the thinking behind flexing what is being delivered and not just do it ‘because that’s what the manual says’. The following sections outline the deeper and more specific reasons why PRINCE2 Agile involves basing the way a team thinks and acts on a different paradigm from that on which projects have traditionally been based.

6.4.1 Being on time and hitting deadlines

For any project or piece of work being on time is naturally seen as desirable, but the advantages that meeting deadlines creates may not all be obvious; when the many upsides of this are taken together, it creates something that should be seen as essential as opposed to just desirable.

Some of these advantages can include:

  • delivering early realization of benefits, and these can be planned around
  • helping with planning (e.g. dependencies within a project or between projects, capacity and resources at the portfolio and programme level)
  • giving confidence (e.g. with progress)
  • there may be no choice (e.g. external market forces or regulatory considerations)
  • reducing the likelihood of cost overruns (assuming that resources are fixed)
  • improving reputation (e.g. with the customer).

‘Being on time and hitting deadlines’ applies to any timescale – short-term (e.g. a 2-week sprint), medium-term (e.g. a 2-month stage) or long-term (a 6-month project).

6.4.2 Protecting the level of quality

Any framework for projects or product delivery strives to ensure that the appropriate level of quality is achieved. However, in practice does the level of quality suffer (or is at risk of suffering) due to the very nature of the approach being used? For example, when using a traditional Waterfall lifecycle that is broken down into ‘technical’ phases such as analyse, design, build, test and implement (NB: PRINCE2 is built around ‘management stages’ and not ‘technical stages’), there is a risk that frequently materializes of the earlier phases overrunning, leading to later phases becoming compressed in order to deliver on time. The most common example of this is where quality checking or testing is reduced in order to meet deadlines.


Technical phases (such as analyse, design, build, test and implement) take many forms and can cover such terms as requirements, planning, deployment, integration, acceptance and construction.

There is a likelihood that this leads to ‘short-term gain but long-term pain’ (e.g. a product goes into operational use on time but it contains errors that were missed during quality checking and testing, and several products need to be recalled).


Acceptance criteria are commonly used in agile to assess whether a user story has been completed. They are the equivalent of quality criteria in PRINCE2.

The concept of flexing what is being delivered ensures that the emphasis is on delivering less scope or using lower-priority quality criteria, as opposed to compromising the overall quality level of the final product (as described by the customer’s quality expectations and the associated acceptance criteria).

Compromising the quality level of anything delivered during a project can take many forms but results from such situations as:

  • reduced testing
  • incomplete documentation
  • sub-optimal design
  • lack of appropriate training (e.g. for end-users, customers, support teams)
  • non-compliance with standards.

The result of any compromise to the level of quality can have damaging long-term effects in terms of the total cost of ownership of the final product as it may suffer from:

  • reduced usability
  • significant support requirements
  • degraded performance
  • lack of engagement with the user community.

Therefore, this should be avoided. PRINCE2 Agile protects the level of quality and ensures that deadlines are met by reducing the amount delivered by the project but not reducing activities that ensure that the quality level is met.

6.4.3 Embracing change

Change is inevitable when working on anything difficult so it is best to expect it and prepare for it. Change can take the form of a new idea that has not previously been thought of or a misunderstanding where an assumption proves to be incorrect. Change should be seen as positive because a more accurate final product is likely to be produced.

It is important to distinguish between minor change (e.g. to the detail) and major change (e.g. to the project baseline) because only the former can be handled dynamically and with little overhead. This illustrates the importance of setting the project baseline in the project initiation documentation (PID) at the correct level (e.g. avoiding unnecessary detail early on).

Definition: Trading (or swapping)

The act of handling change by replacing one or more requirements (or features or user stories) with others of a similar size in terms of effort.

Minor change can be handled by flexing what is being delivered through prioritization and trading (or swapping), whereas major change would usually require more formal change control processes and may even necessitate going into exception and/or stopping the project if the business case is no longer viable.

6.4.4 Keeping teams stable: avoid adding new team members

If a project falls behind schedule a traditional response would be to consider the option of increasing the number of people involved in order to speed up progress. If the work being undertaken is reasonably straightforward, this can solve the problem. However, when the work is more challenging it probably will not – particularly in the short term. This is the primary reason why the tolerance for cost is set to zero.

Although this has an impact in any situation, the agile way of working is particularly impacted by the changing of personnel. This is because agile utilizes such things as informal communication and self-organizing while scheduling work into short timeframes (e.g. a 2-week timebox). Therefore, changing team members or adding to the team can have a far more detrimental effect than normal for reasons such as:

  • Time is spent bringing new team members up to speed.
  • The number of communication lines in the team grows exponentially.
  • There is an opportunity cost incurred to the areas providing the new people.
  • The team dynamics change and need to be re-established.

The impact of changing a team’s dynamics is usually underestimated and can sometimes be the most counter-productive side-effect of the four.

Definition: Team dynamics

The interpersonal interactions between the individuals on a team. This relates to the culture and attitudes of the people in the team and needs to be managed carefully: it can be a very positive and powerful force when it is working well, but it can be destructive when it breaks down.

It is important to understand that team members may need to change throughout the life of a project as the needs of a project change, but this concept of avoiding the use of extra people to improve progress applies primarily to the short term – for example 4 weeks or less, such as within a sprint.

6.4.5 Do we need everything we have asked for?

Usually no, although the customer may not realize this at the start of a project. This point can be easily demonstrated by looking at products we frequently use, and analysing how many of the functions and features we rarely or never use. A washing machine is perhaps a good example of this because it would normally contain many functions and features as well as a wide range of spin speeds, temperature settings and programmes. It would, however, be unusual to find many people who used more than just a few of the options available. Most people would use two programmes at most.

The importance of this concept lies in the PRINCE2 Agile belief that the features of the product are the safest and most sensible area to compromise on (i.e. to use as contingency). A project using PRINCE2 Agile does not set out with the intention of not delivering everything, but it does aim to hit deadlines and protect the level of quality by reducing what is delivered accordingly. This in turn can result in the early delivery of a minimum viable product (MVP), and in general terms the project delivers what the customer really wants (or needs) more quickly.

Previous Section   Next Section