PRINCE2 Agile 2016
Previous Section   Next Section

10.4 Different concepts regarding roles between PRINCE2 and agile

PRINCE2 operates in any environment and on a project of any size from something simple and straightforward to something more challenging. Some commonly used agile concepts and roles may therefore need to be adjusted and the following guidance applies:

  • Agile delivery teams prefer to be led and coached as opposed to managed. Much of the agile way of working is founded on teams being self-organized and collectively responsible for what they deliver. The Scrum master is seen as a coach and a servant leader to the team and not a manager of the team. PRINCE2 defines the role of team manager, which has clear accountability at the team/delivery level; the mapping of this to any role in an agile team is not straightforward and needs to be handled appropriately (see section 10.4.1).
  • Common agile guidance refers to a single product owner. If a project involves more than just a handful of people and needs to canvass the views of several stakeholders and perhaps conflicting views from the customer’s side, PRINCE2 Agile recommends taking a more blended view of the customer rather than listening to one single voice. This would mean engaging with the customer at different levels of authority and ensuring that all areas of expertise have been included in the decision-making and communication process (see sections 10.4.1 and 10.5.2).
  • Common agile guidance does not have a project manager role. Unsurprisingly, PRINCE2 sees this role as mandatory on the basis that if a piece of work is difficult enough to be classed as a project then it requires someone to carry out the role of managing it.

10.4.1 Integrating the PRINCE2 team manager role into an agile delivery team

A PRINCE2 team manager has a clearly defined set of responsibilities which cover five areas as shown in the left-hand column of Table 10.2. The table also shows how these responsibilities correspond to the most common agile roles.

Team manager: areas of responsibility Covered by the Scrum master? Covered by the product owner? Covered by the delivery team?

Planning

No, but may facilitate and support

Yes (prioritizing)

Yes (sprint planning)

Monitoring and managing progress

Yes (by way of coaching the team to self-organize)

Supports this through self-organization and by making the product backlog transparent

Supports this through self-organization and by making the sprint backlog transparent

Liaising with the project manager and other stakeholders

Most likely to but not necessarily (see guidance in this section)

No

No

Managing issues and risks

Yes

No, but will identify them

No, but will identify them

Final acceptance and handover of products

No

Yes

No (but the team is responsible for delivering them)

Table 10.2 Mapping the responsibilities of a PRINCE2 team manager to the common agile roles (in this case Scrum)

The team manager role in PRINCE2 needs to integrate with the delivery team as shown in Figure 10.3.

Figure 10.3 Integrating the team manager role into an agile delivery team

Figure 10.3 Integrating the team manager role into an agile delivery team

10.4.2 Relationship types linking the project manager and the delivery team

There are three options available when integrating an agile delivery team into a PRINCE2 project structure with respect to the team manager role. The key point is that the project manager needs to liaise with the team in the five areas of responsibility described earlier in Table 10.2 (see Appendix B for descriptions of roles).

Option Considerations

Leave the delivery team roles as they are

  • Ensure that everyone is aware of who is responsible for each of the five areas.
  • Role names remain the same (e.g. product owner, Scrum master).
  • No-one is referred to as the team manager.
  • The project manager will liaise with more than one person in the team.

Leave the delivery team roles as they are but identify a single point of contact for the project manager

  • The single point of contact could be anyone from the team but is most likely to be the Scrum master and may be the product owner.
  • Role names remain the same.
  • The project manager will liaise with one person in the team, who will be able to provide the project manager with the information they need.
  • The single point of contact may, or may not, be referred to as the team manager.

Create a team manager role in the delivery team

  • This role would cover all of the areas of responsibility in Table 10.2.
  • This is best achieved if the team manager is highly collaborative and facilitates the self-organization of the team – the team manager remains ultimately accountable for the outputs in these areas but not necessarily for creating the outputs.
  • The project manager will liaise with the team manager.

Table 10.3 Integrating the project manager with the delivery team – options to consider

PRINCE2 Agile does not have a preference for any one of the three options outlined in Table 10.3 as it will depend on the maturity of the delivery team and the relationship between the project manager and the delivery team. It may be that the project board, who are ultimately accountable for the project, express a preference or make a decision.

These three options could be said to represent a range from ‘very agile’ (at the top) to ‘less agile’ (at the bottom) and could be a sign of how mature an organization is with respect to the agile ways of working. However, each project has its own set of unique circumstances and the choice should be made according to those circumstances.

The relationship between the project manager and the delivery team is one of the most important areas to get right when using PRINCE2 and agile together. This may need to be defined as part of a work package, and it should be defined in the project initiation documentation (PID) as this is where the project board (and perhaps the project manager) will need to agree on an appropriate interface between the project manager and the team manager/delivery team. Potentially, the relationship may be different from team to team.

How to integrate the responsibilities of the team manager into an agile delivery team is ultimately about balancing the needs of the project board and the project manager to enable them to direct and manage the project while at the same time creating an environment for the teams that motivates and empowers the people delivering the products.

10.4.3 The composition of a delivery team

There is no mention of the composition of the delivery team in PRINCE2. This is for two reasons. Firstly, PRINCE2 operates in a variety of situations and industry sectors; therefore defining delivery teams is difficult as there is a wide variety of disciplines to cover. Secondly, the technical delivery aspects of a project are separate from project management and project direction. All that is required by PRINCE2 is the clarification of the relationship between the project manager and the team manager.

Agile does define the roles in and around a delivery team, and they would usually represent some or all of the following:

  • someone to lead the team
  • someone from the customer (or at least someone to represent the customer)
  • a team to create the product
  • someone to assure the quality of the product
  • someone to coach the team (which includes coaching them in agile).

How many of each role will vary according to the needs of the delivery team. One person could do more than one role (e.g. lead the team and coach it). Several people could carry out one role (e.g. create the product). Some roles may be peripheral to the delivery team (e.g. from customer areas that provide relatively minor input). A typical guide for the size of a team is seven, plus or minus two. It may be better for delivery teams that are larger than this to be divided into more than one team.

Many agile roles appear to assume an IT context: therefore role descriptions can look very much like IT roles, using terms such as ‘developer’ and ‘business analyst’. There is usually very little mention of roles such as engineer, designer, editor, etc. PRINCE2 Agile provides the following set of generic roles that can be used if desired (see Appendix B):

  • customer subject matter expert (SME)
  • customer representative (usually outside the delivery team)
  • supplier SME
  • supplier representative (usually outside the delivery team)
  • delivery team quality assurance (QA).

10.4.3.1 Multi-skilled people and roles

Many in the agile community promote the idea of teams made up of multi-skilled people, where any team member can do any other team member’s job. Others agree with having more than one skill, but prefer some degree of specialization. There is very little appetite for single-function roles in an agile delivery team, as this makes self-organizing and the ability to respond to delays very difficult.

Organizations developing their agile capability and looking to broaden people’s skill-sets need to allow enough time for this transition to take place. When using PRINCE2 with agile it is recommended to aim for delivery teams that are made up of ‘generalizing specialists’ (sometimes referred to as ‘T-shaped’ people as they have a lot of depth in one particular skill, and a breadth of knowledge, to a limited degree, in other skills). This creates a team in which everyone has a core skill, but they also have the ability to help out other team members (to some degree) in other areas of expertise.

Furthermore , the whole project management team needs to be set up in such a way that any stakeholder who needs to contribute is aware of their role (e.g. to provide information or to assure deliverables). Various techniques such as RACI (see box) exist for analysing stakeholder involvement – assessing the contribution, commitment and support levels of stakeholders in terms of whether or not their involvement is critical, desirable or non-essential. Such techniques can be used to ensure that the project management team is set up correctly and that the communication management strategy complements this. Ultimately, all of this will be approved by the project board.

It is essential that the delivery teams are clearly empowered, as they will be responsible for self-organizing and delivering products that are fit for purpose. Ensuring that the people in the delivery teams are appropriately trained in agile may also be needed. A lot of agile training is focused on specific delivery roles such as the product owner, the Scrum master and the agile coach, and corresponding qualifications also exist.

Definition: RACI

A model used to help define roles and responsibilities. RACI stands for ‘responsible, accountable, consulted and informed’.

In some senses, PRINCE2 has no interest in the inner workings of a delivery team. It uses the work package and the Managing Product Delivery process to ensure that the required product is delivered. However, to fully embrace agile, the PRINCE2 project team, and particularly the project manager, need to be aware of how people using agile work and behave – specifically at the delivery level. They must not meddle or interfere with the delivery teams as this is likely to be counter-productive, but the project manager needs to understand how agile is helping the project: this applies across the project as a whole and not just at the delivery level.

A PRINCE2 project manager using agile will be interested in how the delivery teams are working when liaising with their team managers. Therefore, they need to be aware of the delivery team roles and their typical behaviours.

10.4.4 Single-team project structure

If a project is small enough to be addressed by one team where the roles of project manager and team manager are combined, an expected configuration of the customer and supplier roles would look something like that shown in Figure 10.4.

Tip

An independent quality assurance (QA) role means that there is a separation of duties and people do not ‘mark their own homework’ (hence the need for the role).

Image

Figure 10.4 An example of an organizational set-up for a project with one team

Notes:

  1. Supplier subject matter experts (SMEs) would typically be full-time.
  2. Customer SMEs may be full-time or part-time depending on their role within the organization as a whole (i.e. they may have a ‘day job’ as well as a role on a project).
  3. On a single-team project the high-level view of the customer could be covered entirely by the senior user role, although other customer representatives at this level may be formally involved.
  4. The detailed view could be covered by one customer SME, although more than one customer SME on a small project is quite normal when using PRINCE2 Agile. This will typically be similar to the product owner role, although in a basic agile context there is usually only one product owner.
  5. Delivery team quality assurance may be the responsibility of just one person or it may be split into two roles (one to cover the customer side and one to cover the supplier side).

10.4.5 Multiple-team project structure

If a project has more than one delivery team there will be one project manager and more than one team manager, and a typical configuration of the customer and supplier roles would look something like that shown in Figure 10.5.

Image

Figure 10.5 An example of an organizational set-up for a project with many teams

Notes:

  1. There may be more than one person wishing to contribute to the high-level customer view as a senior user. In a mature agile environment, if there is one person ultimately responsible at this level, then this is sometimes referred to as a ‘super product owner’, ‘senior product owner’ or ‘product manager’. The senior user role does not typically map to the role of product owner found in a delivery team.
  2. A customer representative may wish to contribute to both the high-level and the detailed-level understanding of a project.
  3. A customer subject matter expert (SME) is the focal point for all information about the customer at the detailed level. They act as a conduit to the delivery team for all views that need to be taken into consideration from any customer representative who is impacted or who may wish to contribute. The high-level view is provided by the senior user.
  4. A customer representative may contribute to more than one team at the detailed level.
  5. A team may have more than one customer SME. It may be appropriate to determine any reporting lines between customer SMEs in the same team but usually this is not necessary. Suppliers may also have their own SMEs.
  6. Customer representatives need to have clearly assigned roles on a project, but their involvement is significantly less than that of a customer SME. They usually contribute specific knowledge from certain areas.
  7. A coach may exist as a person carrying out a specific role in a delivery team or the role could be covered by a person who is also carrying out another role for the team (e.g. team manager). Alternatively, a coach may work with several teams and be provided by project support.
  8. QA may be split into customer QA (CQA) and supplier QA (SQA) and could be carried out by people from outside the delivery teams.
  9. A customer SME could also carry out CQA.

Tip

Customer QA and supplier QA are split into two so that it is possible to check that:

  • The thing has been built right

    and

  • The right thing has been built.

10.4.6 Tailoring the PRINCE2 roles

Outside the delivery teams, PRINCE2 has agreed and identified roles and responsibilities. All of the roles apply when using agile and their responsibilities do not need to change. However, each role would need to be conversant with the fundamentals of working in an agile way. Additional guidance is provided in Table 10.4.

Role Overview of the tailoring required and further considerations

Project board

Needs to be fully conversant with the agile way of working and needs to understand:

  • The fact that everything might not get delivered.
  • The implications of the degree of agility being used – the project board needs to authorize the intended level of use of agile and ensure that it does not create unnecessary levels of risk. Risks can be created by using too much agile, or not enough agile, in relation to the project environment.
  • The mixture of PRINCE2 and agile is a coherent blend and they do not exist in parallel.
  • The different emphasis on self-organizing and communications techniques will necessitate that the appropriate boundaries are correctly set up to enable management by exception, giving the project board the appropriate level of control, and the project manager and the delivery teams the necessary empowerment and trust.
  • The general level of agile knowledge within the organization and how this will impact the project (e.g. agile knowledge of the people representing the customer on a project).

Executive

Needs to be familiar with the term ‘value’ as this will be frequently used by the project management team and the delivery teams. The term is often used interchangeably with the word ‘benefits’ and although they are similar in how they can be used, they are not identical.

Knowledge of how PRINCE2 integrates with Management of Value (MoV) would be beneficial.

This role broadly maps to agile environments that refer to a role of ‘sponsor’.

Senior user(s)

This role is unlikely to map to the common agile role of product owner, although it may function as a ‘super product owner’ under some circumstances.

It is an important role in PRINCE2 Agile, in that it is the role that is ultimately responsible for the prioritization of the work being delivered in order to maximize value and realization of the customer’s goals.

Senior supplier(s)

No further guidance is required to that already mentioned for the project board above and the role description in Appendix B.

Project manager

Needs to be fully conversant with the agile way of working and how to manage a project using agile. Furthermore, the project manager is responsible for ensuring that the use of agile is happening in the right way and that the project management team is receiving the appropriate coaching and support.

The project manager needs to be seen as a friend of the delivery teams and not a figure of authority.

This role does not naturally correspond to the Scrum master.

Team manager

This is an important role when using PRINCE2 in an agile context and represents the main interface between project management and product delivery.

See section 10.4.1 for a detailed explanation of the tailoring required.

Change authority

Will need to be aware of the agile way of working (e.g. the focus of tolerances set for the project will be in the form of flexing what is being delivered, and the delivery teams will be empowered and self-organizing).

Project assurance

This has an important role to play in ensuring that management by exception is operating correctly to support the agile way of working.

They need to assure that the project manager is being agile and applying agile in the appropriate way.

They also need to assure that the delivery teams are using agile appropriately, and this would include the team manager.

They may wish to put particular emphasis on the interface between the project manager and the team manager role as this may have been set up with a particularly agile emphasis or a more formal emphasis. Either way, it needs to be functioning in the most effective way possible for each team (see section 10.4.2).

Project support

May be responsible for the provision of agile coaching to the project management team or at the delivery team level unless the delivery team already has someone in that role.

Corporate and programme management

Will need to be aware of the agile way of working (e.g. the use of empowering the project management team and frequent releases of products to enable and provide benefits). They may also be looking at the organization as a whole and how the agile way of working can be applied or improved.

Table 10.4 Guidance on the PRINCE2 roles and possible agile mappings

Previous Section   Next Section

Expand