PRINCE2 AgileTM

PRINCE2 Agile™ is a project management framework based on the methodology of PRINCE2. Despite the fact that PRINCE2 is considered a Classic or Waterfall method (which is not completely true), Agile principles can be blended together and nothing from the present theory would block the Agile approach. On the contrary. Adding agility into a PRINCE2 project, the area of use of PRINCE2 has been significantly increased and the success rate of a project should therefore also be increased with a higher delivery value to the customer, even at the beginning or during a PRINCE2 AgileTM project.
The lead author of PRINCE2 AgileTM is Keith Richards and the owner of license is AXELOS (which also own the license of PRINCE2). PRINCE2 AgileTM was developed based on good practice from PRINCE2 project management, and it also incorporated diferrent Agile frameworks, such as Kanban and Scrum.
 

What remains and what is changing

To consider a project as a PRINCE2 project, there must be valid principles; this remains in PRINCE2 AgileTM. In order to implement other Agile principles into PRINCE2, PRINCE2 AgileTM introduces five behaviours which are typical for all Agile projects. They are:
1. Transparency – the most important elements of this principle come in the form of the common Agile values of honesty, trust, integrity and respect.
Transparency is not just visibility as understood by putting information on the Progress Board (or Kanban Board), it is more about revealing and sharing information with everyone, which might be good as well as bad.
2. Collaboration – it is more than just cooperation. Empowered, self-motivated teams work as one unit. Collaboration is about sharing any problems and taking a common approach to find the best solution. And Collaboration does not only mean internal to the team. It is also external, mainly with stakeholders, users and business representatives to make all of them responsible for the success of the project.
3. Rich communication – is much more than just sending reports to the next level of management. Rich communication is more about face-to-face communication (if teams are not located in one place, then using some high tech communication channels if possible with video camera). It is generally known that more than 70% of communication is non-verbal, so the advantage of face-to-face communication is in fast and clear understanding, immediately solving problems, etc. The strongest tools and techniques of rich communication are daily standup meetings, planning, review, and retrospective meetings.
4. Self-organization – means trusting the team to organize the work since they know best how to get the job done. If plans must be made, then invite team members to help doing so. The more they feel that it is “their plan”, the more the plan will be followed. Self organizing creates mutual respect. Therefore, the Project Manager should appoint a Team Manager to focus on product delivery, and he will do it better if he feels trusted.
5. Exploration – is about learning and feedback. In order to create the right thing, it is necessary to first know what the right thing is. Learning helps to improve the product. It is usually by using experiments, prototypes, and spikes that help better understand the customer expectations, get quick feedback and reduce the impact of mistakes. Faster feedback to the team means that  quicker progress can be made. The sooner the team solves “known unknows” and uncovers “unknow unknows”, the sooner they can arrive at the right destination.
 

5 behaviours (principles) in PRINCE2 Agile projects

Fixing and Flexing in PRINCE2 Agile projects

A typical feature of Agile projects is that the customer gets value fairly quickly from the project, but probably won’t get everything he wants. Therefore PRINCE2 AgileTM introduces the concept of Fixing and Flexing.

Typical feature of agile projects is, that customer gets value even soon in the project, but probably does not get everything he wants. Therefore PRINCE2 Agile introduces the concept of Fixing and Flexing.
 

What is Fix and what is Flex

Time - FIX

There is zero tolerance for extra time for a Project Plan. Considering that negative tolerance (the project should finish sooner) is not relevant, because the project should deliver “SHOULD” or “COULD” components in the remaining time.

Cost - FIX

Cost - FIX The project cannot exceed the agreed budget. Again, if major components are delivered with lower cost, extra budget can be used to deliver “SHOULD” and “COULD” components.

 

As you can see, in the area of time and costs, PRINCE2® AgileTM is stricter than the standard PRINCE2® method, which allows that the project plan might have tolerances on time and costs given by the corporate/programme.

Quality FIX and FLEX

The level of quality is protected, but it is clear that not all quality criteria (products) and acceptance criteria (project product) are of equal importance for the customer, so they can be prioritized. It is necessary to fix essential customer quality expectations, but FLEX-ing those acceptance criteria is more desirable.

Scope – FIX and FLEX

FIX and FLEX Not everything that the project is going to create has equal importance for the customer. There is zero tolerance (FIX) for essential products, but other products which are of lower priority might not be delivered.

Risk - FIX or FLEX

 FIX or FLEX Tolerance to be defined according to the needs of the project board and Project Manager as this depends on the specific situation.

Benefit - FIX or FLEX

FIX or FLEX Zero tolerance for the level that is defined as “minimum viability” in the Business Case. Tolerance might be used above “minimum viability” to add extra benefits.

 

Fix and Flex principle in PRINCE2 Agile projects. Time and cost is FIX.

There are 5 targets to further explain the concept of fixing and flexing.

 

Target

Explanation

1

Be on time and hit deadlines

Being on time and hitting deadlines has many and very significant advantages.

2

Protect the level of quality

Ensuring that the level of quality is protected and regarded as vital is of paramount importance to a project. This will lead to a lower cost of ownership through the lifetime of the final product.

3

Embrace change

Embracing change by seeing it not only as inevitable but also as a positive influence on a project, allows for a more accurate final product.

4

Keep team stable and not add people to a team to try to go faster

Keeping the team stable over the short term removes the temptation to add people to a team in order to catch up with work when in reality it is more likely to have little or no effect.

5

Accept that the customer does not need everything

Accepting the premise that not everything defined in the initial stage of a project must be delivered. It inevitably turns out that many things do not add enough value to warrant delaying the project because of them.

 

Agilometer and Cynefin

Before the Project Manager starts the project, he must understand how complex the environment is and which risks exist in implementing an Agile approach.

Cynefin

The Cynefin framework was created by David Snowden to measure the level of complexity of a project. It is a decision-making framework that has been designed to help with understanding and determining what level of complexity exists in any given situation or environment.

There are five relations defined:

Obvious – where the relationship is obvious and is usually addressed by “best practice”.

Complicated – where some form of analyses or expertise is required to understand the relationship, which is usually addressed by “good practice” where there might be several options available.

Complex – where the relationship can only be understood in retrospect and is addressed by “emergent practice” which may evolve to a new way of working.

Chaotic – where is no apparent relationship and any way of working is described as novel.

Disorder – where the relationship is unknown.

Cynefin (Kinevin) framework to verify the environment in PRINCE2 Agile projects

Agilometer

The task of Agilometer is to best estimate different areas of risk when applying Agile project management. Every project situation is different in some form due to factors such as the level of trust between the customer and supplier, the technology being used, or the level of uncertainty.

In order to receive the most benefit from using a method or approach it is essential to adjust and adapt it to suit the context and conditions it is operating in.

In order to tailor PRINCE2® in the best way possible, it is important to assess in what context a project exists with regards to the environment and the working relationships. To achieve this, PRINCE2 AgileTM has an assessment tool called Agilometer to answer the question “How Agile can we be on this project”?

The Agilometer looks at six key areas and the Project Manager is responsible for canvassing the key stakeholders involved in the project as to what values to give each category. Each category is represented on the figure by a slider.

 

Agilometer in PRINCE2 Agile projects

  1. 1.     Flexibility of what is delivered

    Customers understand that not everything is going to be delivered, that changes might appear and these changes should be incorporated into the project. The customer is familiar with prioritization techniques (e.g. MoSCoW) and is willing to participate actively on prioritization of products (user stories).

    2.     Level of collaboration

    The team is “set up”; gave excellent results in the past; there are no “unsolved” conflicts; team members accept positive critique and accept that they make mistakes; people work quickly, effectively and help each other; and they are used to working in a partnership environment between the customer and supplier.

    3.     Ease of communication

    Communication is informal and easy among all parties involved; people are used to face-to-face communication; and are used to working with prototypes and models. There is high level of visibility of progress; plans and results (mainly via a progress board, issue and risk logs); people are collocate or at least has a high level of visual communication technology introduced. Formal communication and reporting is limited.

    4.     Ability to work iteratively and deliver incrementally

    Benefits to the customers should be delivered in partial deliveries; work is done iteratively and refined in the later stages; there is experimenting and exploring and fails present big learning and improvement options. Everybody understands that the product might not be perfect the first time and that incremental delivery brings quick and frequent feedback which increases the deliverability and benefits to the customer.

    1.     Advantageous environmental conditions

    The overall working environment is very supportive of working in an Agile way. Full-time people are assigned to work on the project; they have appropriate skills; and the team is stable and experienced. Any external parties are comfortable working in an Agile way, Agile tools are used and the commercial and contractual environment are favourable to an Agile way of working.

    6.     Acceptance of Agile

    All stakeholders involved in the project are fully aware of the behaviours, concepts and techniques of working in an Agile way and they fully understand the advantage which an Agile way of work brings. Peripheral stakeholders are also aware of the need to carry out their roles in an “agile friendly way”. People are trained in the appropriate way and there are no blockers for using Agile work.

PRINCE2 Agile processes

Since we work with agility, there is no need for very much upfront planning. Also, the project documentation does not need to be very detailed. It seems to be useful to tailor this work and put together Starting Up and Initiation Processes (this way of tailoring is obvious also in standard PRINCE2® projects, for example in small or mandatory projects where decisions about continuation of the project after starting up is useless and a wastw of time, since the project must continue anyway).

 

PRINCE2 Agile processes do not need very much changed.

 

As shown above, agility is best reflected at the product delivery level, less on the project management level, and probably least on the directing level. It does not mean that Development Teams work with Agile and the Project Board works with the standard PRINCE2®. It means that the Project Manager and Project Board members do not need to have such deep Agile knowledge and do not need to make all the decisions purely based on Agile, though the low Agility here  might cause a risk for the project.

The most changes from standard PRINCE2® can be expected in managing the project delivery process. The difference is mainly in the understanding of Time-boxing and understanding that teams must be stable so one or more teams can work together. They will accept the Work-packages at the beginning of the stage and split the work on Sprint. Each Sprint might potentially deliver a shippable product (means a product which should be accepted by the customer and which brings him a value). It should be called a “release” but not every Sprint must finish with a release to the customer.

Work package is then split into Sprints. In Scrum, the length of a Sprint is fixed. In Kanban it is “flow”, which is fixed. When a team delivers everything defined in the work package, they can accept another work package.

Managing product delivery process in PRINCE2 Agile projects

Work package is then split into sprints. In Scrum, the length of sprint is fixed, in Kanban it is flow, which is fixed. When a team delivers everything defined in the work package, they can accept another work-package.

Organization

PRINCE2® defines eight project management team roles while four of them are not mandatory. This huge flexibility will also be used in Agile projects, but some additional roles will be added.

The most significant change is the introduction of project Development Teams as a part of the project and probably other Scrum core roles, the Product Owner and Scrum Master. These roles are working towards managing the product delivery process, which is the “most agile” process in PRINCE2®, while other mandatory roles should be less “agile”.

The project board

As I described in the past chapters and as stated in PRINCE2 AgileTM, Targets (accept that the customer does not need everything), Project Board members and mainly the Senior user(s) must understand:

  • The Fixing and flexing concept
  • The idea of prioritization and how it is implemented in the project
  • Must accept that the initial Project Product description (or Product Vision) will be vague to a certain extent
  • That non-baselined products should be changed without their authorization
  • That if a stage does not deliver everything which was planned, it is not a failure
  • That the customer MUST regularly interfere with the Development Team
  • That the project documentation will be less strict
  • That the majority of reporting and communication will be done orally or visually.

The Project manager

The Project Manager is not a preferred role in Agile projects and the majority of standards do not recognize it. An Agile team prefers to be led and coached and not managed or directed. Nevertheless, in PRINCE2 AgileTM this role is mandatory, but must adopt a certain level of Agile behaviour, mainly servant/leadership. First of all, the Project Manager must accept that Development Teams and team members form the significant part of the project and that they are self-directed and self-motivated. He can still authorize the work in the form of Work Packages, but their content should be discussed and agreed with the team.

The Project Manager remains an intermediary between the Project Board and the Development Team and will have significant responsibility on planning, monitoring the progress, and managing the project.

Team manager

The Team Manager role is not mandatory in PRINCE2® so it is neither mandatory in PRINCE2 AgileTM, but the reason might be different. In a small PRINCE2® project, the Project Manager manages the team since there is no need for an intermediary. In PRINCE2 AgileTM this can also be the case, but also because the teams are self-organized and self-motivated.

Project Manager vs. Project Team

In general, there are three options on how a Project Manager can deal with Development Team:

  • Leave the team roles as they are which means that no-one is the leader and the Project Manager might communicate with more than one person in the team. The Development Team is the unit responsible for doing the work.
  • There is one person from the team responsible for the communication with the Project Manager. It might be anyone in the Development Team or even the Scrum Master.
  • There is a Team Manager role responsible for the communication with the Project Manager. This is best achieved if the Team Manager is highly collaborative and facilitates the self-organization of the team. In this case, the Team Manager is accountable for the result of the team, but might not necessarily be working in the Development Team or creating the products.

Scrum master

As the name says, this is typical role in a Scrum team. He is primarily responsible for ensuring that the team has a productive work environment by guarding the team from external influences, removing any obstacles and enforcing Scrum principles, aspects and processes. His role is very different from the role of Project Manager. The similarity is on a coordination level – if there are more Development Teams in the project, either Scrum Master can participate on Scrum of Scrums meetings (if they exist), or the Project Manager can take over this responsibility.

Product Owner

This role is characterized as the voice of the customer. It means it represents the interest of the customer in the team. This is one of the bottlenecks recognized by PRINCE2 AgileTM in that one person has probably very little to no representation of the different requirements of the customer. There PRINCE2 AgileTM declares the wider representation of the customer in the Development Teams. His main responsibility is to prioritize the product backlog, define acceptance and done criteria and accept user stories at the end of Sprint. AgileTM is not strict in what the project team should look like. There is only the requirement that the Project Manager must be defined coming from PRINCE2® and self directed and self motivated team(s) must exist coming from PRINCE2 AgileTM.
The role of the Team Leader might be taken by an independent person or by the team, and the role of the Scrum Master does not have to be an independent person, but might be taken by the Project Manager or the Team Manager. The role of Product Owner might by fulfilled by the presentation of a customer in the team by Quality Assurance or some other stakeholder.