10.5 Agile concepts and techniques
10.5.1 Servant leadership
This concept or philosophy is usually advocated as a best practice for the person ‘leading’ a team at the delivery level in an agile environment. The term ‘servant leader’ originates from books and essays written by Robert K. Greenleaf in the 1970s, although it could be said to date back to ancient history.
10.5.1.1 The basics
Although servant leadership can be used anywhere it is generally aimed at corporate or organizational leadership, or those who ‘lead’ as opposed to those who ‘manage’. The term is referenced by the Scrum method (although the term is not explained); through the wide adoption of Scrum, servant leadership now has widespread adoption too as a concept, although how far it can be adopted is often affected by existing organizational constraints.
In simple terms the idea of servant leadership is that the best way to lead a team is to be a servant to the team. Therefore, as a leader of a team you would put team members’ needs above yours. It would be your role to ensure that everyone is looked after, that they are okay and they have what they need. This in turn creates a happier, more effective and productive team, and performance improves accordingly.
When integrating agile with PRINCE2 this concept needs to be handled carefully, as it could be said that some of PRINCE2 would be in conflict with the philosophy of servant leadership. An example of this would be a team manager who has clearly defined responsibilities such as planning and monitoring the team’s work. Agile and servant leadership focus on everyone in the team as a whole being responsible for how they work and what they produce. Therefore, creating a role for this will automatically create a situation where the team may not feel that it is truly responsible. Even the title of the role itself can produce this effect. However, PRINCE2 does not have a preferred style of control and leadership, so it can support any style and this includes servant leadership.
10.5.1.2 Further information
When using servant leadership, it is important to focus on creating an environment in which the team feel truly empowered and responsible for the way they work and the products they produce, even if the team manager still remains ultimately responsible. This can be achieved by the team manager leading by example and working collaboratively with the team to achieve this.
When using PRINCE2 in an agile context, someone still needs to manage and lead the team, but by using the style of a servant leader their focus will primarily (but not solely) be on helping and supporting the team (i.e. serving). Therefore, leadership of the team is a secondary focus and comes from how well the primary focus is achieved.
In some cases different terminology is used to achieve the servant-leadership philosophy (e.g. ‘facilitative’ leadership or ‘collaborative’ leadership).
A lot of the thinking behind servant leadership is that people feel more valued when they work as equals and share responsibility. This is in contrast to autocratic, dictatorial or authoritarian leadership where those in charge enjoy the feeling of power and the kudos that comes with it.
Servant leadership will fit into any PRINCE2 Agile role where leadership skills are needed (e.g. project board, project manager and team manager) although certain areas of responsibility may need to be defined. An example of this would be to clarify the difference between leadership and management. Leadership normally refers to such things as vision, direction and the ability to inspire. Management focuses more on the work to be done and the people doing the work. There is an overlap between these two, as leaders sometimes need to manage people, and managers always need to lead in some form.
Some of the agile behaviours focus on collaboration, respect and honesty, which is very much in keeping with the servant-leader philosophy; these behaviours would be typical of an agile team manager managing a team with a servant-leader style.
It is possible for a team to naturally select its own leader/Scrum master, and this may be anyone from the team – not necessarily the most senior or most experienced.
10.5.1.3 Hints that may prove useful
A team manager running a team in a servant-leader style would create an environment to help grow and develop team members. The team manager would be a team player, always coaching the team and building consensus along the way. The same applies to a project manager in the wider context of a project management team. Creating a culture where people are comfortable to ask for help, and when they do it is welcomed, is a significant part of creating the right environment.
To help further understand the typical attributes a servant leader would need, the following lists may be of use.
Robert Greenleaf (2002) listed the following desired attributes of a servant leader:
- building community
- commitment to the growth of people
Ann McGee-Cooper and Duane Trammell (2012) summarized servant leadership as:
- listen without judgement
- be authentic
- build community
- share power
- develop people
- co-create shared vision.
These attributes are ideal for any team, as this way of working builds on the behaviours that personify agile, by creating empowered and creative teams working in an iterative style and responding to change. Involving the team in decision-making and organizing work would be seen as a normal agile practice by the project manager or team manager even though they are ultimately accountable in a PRINCE2 environment.
10.5.1.4 Context is important
Servant leadership is a very powerful concept, and how far to utilize this depends on many factors. One such factor affecting how effective this can be would depend on the context in which it was being used. How open is a team, department or organization to this style of working? A mature agile organization would use servant leadership and self-organization a lot. Another factor that could limit servant leadership is that a project team is temporary and therefore needs time to grow and bond, whereas an existing BAU team that is stable and has been together over a long period may have evolved its own way of working.
Ultimately, PRINCE2 can support as much or as little of this style of working as is desired because it has no preferred style. There is nothing in PRINCE2 that limits this.
10.5.2 How to incorporate the wider customer view and the product owner role
In agile, the customer view is often represented by a role called the product owner. It is one of the three Scrum roles and is hugely significant in agile terms: executing this role correctly is critical to the successful use of agile because this role is so commonly used. This may require an individual to be trained in how to be a product owner, or they may need the support of a proxy who has the appropriate skills.
However, there is a paradox with this role in that it is simple to define it and assign someone to it, but this simplicity needs to be tailored when used in a project context – even when working in a mature agile environment. The reason for this is that the product owner role is commonly associated with a scenario where there is one team, one product, and work is ongoing such as in a BAU environment. When using the product owner role in more challenging situations, adjustments will probably need to be made.
10.5.2.1 The basics
In simple terms the product owner is the ‘voice of the customer’ and this role covers the following responsibilities as described in the Scrum Guide (see Appendix H):
- clearly expressing product backlog items
- ordering the items in the product backlog to best achieve goals and missions
- optimizing the value of the work the development team performs
- ensuring that the product backlog is visible, transparent and clear to all, and shows what the Scrum team will work on next
- ensuring the development team understands items in the product backlog to the level needed.
Other definitions of the product owner responsibilities in more mature agile environments include the product vision, creating product roadmaps and business case justification.
In terms of their attributes and style of working, a product owner should be:
- very knowledgeable of the customer domain
- an effective communicator
- able to canvass the opinions of key stakeholders
- clear on the vision for the product
- able to define requirements and user stories
- able to define what a successful outcome would look like
- available at all times to the delivery team.
Ultimately, the product owner has the final say on everything to do with the final product. They own it, and they are solely accountable for it. This means that the product owner has the authority to decide what goes into the product, and they are not accountable to anyone else with respect to having to justify it.
10.5.2.2 The simplicity of the product owner role
Crucial to this role, as commonly expressed in agile frameworks, is that there is only one person doing this. This creates the simplicity which many people (e.g. from the technical delivery side) find attractive as it creates a very clear single point of contact and a single version of the truth.
The simplicity of the product owner role can work well in a straightforward BAU context, but there are limitations when working on a project.
10.5.2.3 Limitations due to project size
Project teams (small or large) would typically require a wider and more representative view of a customer’s interests than are perhaps required in a BAU situation.
It may not be appropriate to have one person from the customer side responsible for the many views and angles that exist on a project. There may be high-level views held by certain stakeholders that need to be taken into account (e.g. strategic), along with other more detailed views from a different set of stakeholders (e.g. to do with how the product looks).
10.5.2.4 Limitations due to size of the role in a project context
It is one thing to assign several responsibilities and attributes to a role, but it is something different altogether to find an individual who can carry out that role effectively. The product owner role contains some responsibilities that even in isolation may require advanced levels of skill and may form a discipline (or role) in its own right, in the context of a project.
Gathering requirements, defining them, facilitating communication with the wider customer community of project stakeholders (which would include many contrasting perspectives) and creating buy-in to the way forward is a significant undertaking for even the most experienced individual.
This can be too much for one person as it involves a lot of work, and some of this work involves a high degree of technical skill (e.g. requirements engineering).
A project requires many customer roles in order to correctly reflect the customer’s view. A single product owner may not be the best way to achieve this.
10.5.2.5 Representing the customer view on a project
A one-team, one-product BAU situation can operate very effectively with one product owner. More challenging work needs to be structured as Figures 10.4 and 10.5 show. Most of the common agile frameworks do not have the structures to accommodate this naturally, although DSDM is an exception to this general rule and mature agile organizations will have created their own.
The PRINCE2 Agile role of customer subject matter expert (SME) is similar to product owner if it is inside a delivery team, and it can still be referred to as ‘product owner’ if the team already uses and understands this term and what the role entails. However, in a PRINCE2 Agile context this role would take the general function of providing the customer’s voice at the detailed level. The senior user would be responsible for the wider and higher-level customer view and also be ultimately accountable for what goes into the final product. The executive would be responsible for the business case.
10.5.2.6 Specialist role to support capturing the customer view
Another option is to have a role that can help to define the project’s products (often referred to as requirements) by acting as a catalyst between the customer view and the supplier view. Roles such as a requirements engineer or business analyst would be examples of this. The role could work inside the delivery teams, the project management team or both. This role would be responsible for some or all of the following:
- acting as a translator, as both the customer and supplier will have their own terminology, and then ensuring that both parties understand the requirements
- gathering and correctly writing and defining requirements/user stories along with quality criteria and acceptance criteria
- helping where appropriate by providing support with testing from the customer perspective
- ensuring that requirements prioritization is appropriate (this includes being prepared to challenge decisions where necessary)
- creating and evolving models and supporting documentation
- facilitating discussions and running workshops with the wider stakeholder community
- contributing to information held in the business case
- using techniques to ensure that requirements align with strategic and/or project objectives
- liaising with the senior user, customer SMEs and other customer stakeholders.
10.5.2.7 Getting a blended view
It is very important to represent the customer view appropriately on a PRINCE2 project. The product owner is a very powerful concept but it needs to be adjusted to work in a project context. To create a fully representative view of the customer at all levels and in all areas affected by a project, it is important to build a blended and comprehensive view of the customer needs and perhaps involve specialists to help with this, such as a requirements engineer or a business analyst. It is essential to do this as well as possible as the customer will be impacted by the final product, and they are ultimately justifying the investment.
On a PRINCE2 project the senior user is ultimately responsible for the appropriateness of the delivered product, and the executive is responsible for the justification of the project itself. The product owner role as commonly defined in agile (e.g. in Scrum) operates in the best way from inside the delivery teams.
10.5.3 Working agreements and team ground rules
Many concepts in agile relate to multi-skilled teams that are empowered and self-organize. Creating working agreements is a concept that is used to evolve the effectiveness of a team that is self-organizing. This is achieved by collectively developing a set of team guidelines, or rules, to bring some structure to how the team works and behaves.
Working agreements and team rules include or are similar to policies, team norms or team charters.
10.5.3.1 The basics
These agreements can operate at many levels. Some of them may relate to concepts such as values (e.g. ‘we should be honest’, ‘we should be open’) while others may relate to simple rules about how long a stand-up meeting lasts (e.g. 10 or 15 minutes), or agreeing the core working hours for the team. They are created and reviewed by the team members themselves (typically during a retrospective) and their purpose is to improve the effectiveness of the team by reducing mistakes and promoting successful behaviours and practices.
Typically they are made visible (perhaps displayed on the wall) and the team develops them over time. The team manager should make sure that everyone is involved, that improvements to the rules are facilitated and that everyone can contribute freely as the features evolve.
10.5.3.2 Further information
All teams are different, and most of the way a team works and acts should develop naturally and not need to be defined. Therefore any rules that are defined should help strengthen the way the team works and provide a focus. Having too many rules could have the opposite effect.
10.5.3.3 Hints that may prove useful
Team ground rules can help with the internal workings of the team. They could be included as part of a work package as long as everyone is in agreement – i.e. the team, the project manager and the team manager.
Agreements and rules are potentially destructive if they are not built carefully by consensus and involve all of those impacted. Some teams prefer to make their commitment to the rules visible by signing them for all to see. Other teams prefer a more cautious approach based on trust and may even avoid using the word ‘rule’, as they perceive this word to have negative connotations because it looks like an order or a command.
A balance between when to guide and when to force is needed. An example of this would be the definition of ‘ready’, which is more of a guide to people, whereas the definition of ‘done’ is something that should be complied with. However, both should be defined collaboratively in order to get commitment to both.
10.5.3.4 The Pastor of Fun
Many in the agile community who have experience of mature agile environments put a lot of emphasis on and effort into creating a collaborative culture in the teams and fostering motivated and happy people. An example of this is where a team creates a role for a person called the Pastor of Fun, and this role is responsible for ensuring that the team develops a close bond by organizing social activities (perhaps inside and outside of work) and coming up with ideas to make certain work activities or events more fun and enjoyable. This typically results in bringing out the more human side of everyone, and in turn this creates behaviours such as loyalty and openness.
The Pastor of Fun is not an official PRINCE2 role.
10.5.3.5 Assessing the needs of the team
Collectively creating agreements on how the team works can be productive, but it needs to suit the requirements of the team. They should decide at what level or levels these agreements need to operate and on what scale they add value. For example, a working agreement could include the following parameters:
- Everyone’s views should be listened to and respected.
- The team is greater than the sum of its parts.
- There is no such thing as a silly question.
- Do not be afraid to say ‘I was wrong’, ‘I need help’ or ‘I do not know’.
- Stand-ups start at exactly 09:30.
- If we cannot solve it ourselves we escalate it quickly.
- Ask, do not tell.
- It is OK to challenge someone’s view.
- It is OK to have fun!