10.2 The general view of agile with respect to the Organization theme
There is a wide variety of structures and ways of organizing teams across the whole agile spectrum. Some agile approaches such as DSDM describe several roles with clearly defined levels of accountability and responsibility, whereas others such as Kanban define none. Scrum sits somewhere in between these two views as it has a few roles but these roles only apply to product delivery.
Agile puts a lot of emphasis on the way a team operates in that it should self-organize, be empowered, remain stable and have a large amount of autonomy. This creates a feeling of the team being collectively responsible for what it delivers, which contrasts with the view that the person in charge of the team is solely responsible. It also prefers the team members to be multi-skilled (i.e. they can offer more than one discipline) as much as possible.
10.2.1 Common viewpoints of agile and roles
Generally speaking the most well-known and well-defined agile roles operate at the product delivery level with relatively little reference made to roles which sit above this (e.g. sponsorship, technical strategy). A mature agile environment would have clearly defined roles that are responsible for areas such as vision and product roadmaps (e.g. a sponsor or a product manager). A summary of how agile views certain common roles is as follows:
- The Scrum master A common role in agile is that of the Scrum master, who is seen as a servant leader (see section 10.5.1). The Scrum master facilitates and coaches the Scrum process while removing impediments identified by the team working at the delivery level. It could be said that there is no equivalent role in PRINCE2. The team manager is the most obvious candidate, but in Scrum and in many agile belief systems the team does not need to be ‘managed’ per se – it needs to be ‘led and coached’. When using agile in a PRINCE2 environment there will need to be a team manager or equivalent who is ultimately accountable for the delivery of a team’s products, but this will need to be handled appropriately as described in section 10.4.1.
- The product owner Another common and perhaps pivotal role in agile is that of the product owner, and this role is often regarded as the key stakeholder. It is difficult to draw a simple parallel with a PRINCE2 role as it depends on the number of delivery teams involved on a project. Even making a general rule is difficult as there may be many teams with many product owners. The product owner role is discussed in detail in section 10.5.2. The business ambassador role in DSDM is similar to this.
- The project manager (and team manager) There is a significant body of opinion in the agile community that suggests there is no longer a need for the project manager role. This view is quite significant and has arisen primarily for two reasons:
- There is a view that any work can be carried out and managed as if it were BAU by breaking the work down to a size and a level of certainty that allows it to be handled as routine work.
- The term ‘manager’ is regarded as having negative connotations to many in the agile community as it infers a lack of trust in the people who make up the team – the belief being that they do not need a manager as they manage themselves collectively though self-organization.
PRINCE2 and PRINCE2 Agile see the project manager role as essential for a project, although in an agile context the behaviours, relationships and responsibilities may be emphasized differently.
- The requirements engineer/business analyst The most common agile approaches give little prominence to a specific role for gathering the requirements for a project (e.g. a requirements engineer or business analyst). This role is usually undertaken by the product owner.