CHAPTER 5: ORGANISATION

This chapter supports the principles of collaborate and communicate.

Agile says:

I think this can be summed up in the words of Evan Leybourn, Business Agility Institute, about an Agile structure:

An organisation that is positioned to adapt to the changing needs of their customers, needs a complementary organisational structure that is both efficient and highly functional. This means a change in the way we think about our organisation. Rather than see the organisation as a pyramid, with executives at the top, graduates and entry level positions at the bottom and everyone else in between; start to think of it has a bee-hive. Hundreds of cells, collaborating towards common goals and outcomes, but ultimately independent in action.⁶

An Agile organisation achieves this by reducing the structural hierarchy and minimising communication overheads through the creation of semi-autonomous, self-organising and cross-functional teams. In this environment, a single, mid-level manager should be capable of supporting 10-20 cross-functional teams, consisting of between 5-9 full-time staff working towards a single, specific outcome.

To understand what an Agile organisation should look like, there are three concepts you need to comprehend;

1: Cross-functional

Cross-functional teams contain all the key skills required to deliver to the needs of their customers. Unlike traditional hierarchical or matrix management structures, cross-functional teams are responsible for the delivery of a product or service from design to completion, and should not need input from, or handover to, other teams at pre-determined stages.

Benefits to this integration include:

•Faster delivery times by reducing handover and communication delays;

•Consistent ownership of work;

•Rapid response to new issues; and

•Improved information sharing across the organisation.

The best cross-functional teams also integrate the customer, or customer representative, within the team. This will significantly improve customer engagement and, by sharing the accountability for delivery, will dramatically improve the overall outcomes.

2: Self-organising

Self-organising teams have the responsibility and authority to create a functional, internal team structure by replacing, retraining, or reorganising team members as needed. This is most evident when the customer’s needs exceed the team’s current capabilities. The team should then self-organise by transferring, or in some cases recruiting, staff with those skills into their team.

There are five factors that teams need to take into account to ensure a complementary team structure.

1.Individual Team Members – will have specialisations and preferences, and whilst they should be able to take on different roles, they may not be as productive.

2.Team Members – should be able to take on multiple roles, though they will not be able to take on ALL roles. You will need a good coverage of skills to ensure role coverage.

3.There is a productivity penalty for context switching – you want Team Members to focus on a specific role and switch only as required.

4.Staff who can take on multiple roles – tend to be more creative in their work.

5.The Customer’s Requirements – drive the structure of the Team, and often require multiple Team Members in the same role to meet them.

3: Self-managing (or empowered)

But by far the largest bottleneck to organisational agility is the bureaucracy and management needed to ensure that team outcomes align to customer expectations and corporate strategy. In an Agile organisation, this can be overcome by giving individual teams the accountability and authority to engage with, and deliver to, their customers without undue interference within the bounds set by the customers’ requirements.

Trust is the most important factor in developing empowered teams. Staff must trust management and management must trust staff. Customers must trust the organisation, and the organisation must trust their customers. Trust comes from communication and respect. Put in place a good communication framework and you are removing many of the impediments to self-management of staff.

A team facilitator may be used to simplify cross-team communication, ensure consensus within a team and align with corporate expectations. Ideally this should be an ordinary team member but may also be a team leader function if required, although it needs to be noted that facilitation and management require different, though complementary, skillsets.

Risks

As with everything, Agile organisational structures and cross-functional teams are not without their risks. For example; understaffed teams may not be able to meet their customer’s expectations, a team may lack members with required or specialised skills, or individuals may be unable to dedicate the time required to the team (through either unplanned leave or other corporate requirements). By being aware of these, and related risks, you can put in place simple resource mitigation strategies.

Final thoughts

There are a lot of processes, techniques and frameworks under the Agile umbrella that can be applied outside of ICT (Information and Communications Technology). But, whatever the ultimate goals, an agile organisation emphasises adaptability and customer interaction, but needs to remain aligned to the core Agile values.

PM4A says:

The PM4A principle covering the project team structure is:

•There should be a simple structure of roles that is repeatable for every project;

•Everyone in the team should understand their role and responsibilities, plus those of the other members; and

•Every role should be clear about where the decision-making authority lies.

Figure 5.1: The PM4A organisation structure

The difference matters because …

The PM4A team structure does not show the involvement of the product owner – a major strength of the Agile methods. The PM4A structure is very flexible according to the project size and roles can be combined in several ways, as shown in the figures below.

Figure 5.2: Combining the roles of client and project manager

This might be the structure in a small project where the client can also act as project manager.

Figure 5.3: Combining the project manager and team leader roles

Again, for small projects it may be sensible to merge the team leader and project manager roles.

These are just two examples combining PM4A roles.

Here is what APM should do:

5.1 Philosophy

Establishing an effective organisational structure for the project is crucial to its success. Every project needs direction, management, control and communication. Before you start any project, you should establish what the project organisation is to be. You need to ask the questions even if it is a very small project. Answers to these questions will separate the real decisionmakers from those who have opinions, identify responsibilities and accountability, and establish a structure for communication. Examples of the questions to ask are:

•Who is providing the funds?

•Where is the knowledge of or link to company strategy?

•Who has the authority to say what is needed?

•Who is providing the development resources?

•How will the project be managed on a day-to-day basis?

•How many different sets of specialist skills are needed?

•Who will establish and maintain the required standards?

•Who will safeguard the developed products?

•Who will know where all the documents are?

•Who can authorise changes? Are there to be different levels of this, depending on the impact of the change (change authority)?

•What are the limits to the development team’s authority and who sets those limits?

5.2 Overview

APM provides an organisation structure that engages everyone involved: the client, product owner and developer interests. Within the structure there are defined roles and responsibilities for every member of the project management team. The project management team is created when Proposing a project and is reviewed as part of the Plan phase to see if changes are needed to fulfil the philosophy. The APM organisation structure is shown in Figure 5.4.

APM has an organisation structure that can be tailored to any project. The way in which APM does this is to talk about roles that need to be filled, rather than jobs that need to be allocated on a one-to-one basis to individuals. In order to be flexible and meet the needs of different environments and different project sizes, APM’s organisation structure define roles that might be allocated to one person, shared with others or combined according to a project’s needs.

Corporate or programme management hand the decision making for a project to the client role.

Figure 5.4: The APM organisation structure

The client is often too busy to look after the project on a day-to-day basis so they delegate to the development team(s), reserving to themselves the key stop/go decisions.

5.3 Corporate/programme management

•Appoint the client.

•Appoint the start-up and initiation team.

•Set any project tolerances of scope and benefits and document them in the project mandate.

•Provide strategic direction.

•Decide on who can authorise changes.

5.4 Client

The client role is appointed by corporate/programme management to provide overall direction and management of the project. The client is accountable for the success of the project and has responsibility and authority within the limits set by corporate/programme management.

The client must be the ultimate decision-maker with the authority to:

•Approve the project plan;

•Approve stage plans; and

•Commit business resources, such as finance, to the plan.

The role also represents the interests of all those who will use, operate and maintain the final product(s), those for whom the product will achieve an objective or those who will use the product to deliver benefits.

The client is ultimately responsible for the project. They should ensure that the project is value for money, ensuring a cost-conscious approach, balancing the demands of business, user and supplier.

Throughout the project the client ‘owns’ the project justification and benefits management approach.

The client is responsible for overall business assurance of the project, i.e. that it remains on target to deliver products that will achieve the expected business benefits, and will complete within its agreed budget and schedule. This should include a role of change authority for major changes to the project’s specification.

5.5 Start-up and initiation team

The work done by the start-up and initiation team is covered in the Propose phase.

This team may be the same team as the development team, but it has specific duties during project start-up and initiation and may require specific skills. It is empowered by the client to identify needs and draw up an outline plan of how to meet those needs.

The roles in this team are team lead, product owner and architect owner. Depending on the project complexity and skills of the team lead, this role may combine with the architect owner.

This team should have the ability to define at a high level what the users need from the project, what type of project approach is selected, how the project will be structured in order to provide these needs and assurance that the project architecture fits in with the environment in which the end product(s) will work.

5.6 Development team(s)

Development teams are made up of three roles: a team lead, a product owner and developers – the number of developers and product owners being flexible according to the amount of work to be done. Development teams should be kept small to avoid communication and control issues.

Development teams are self-organising and choose how best to accomplish their work, rather than being directed by others outside the team. They are cross-functional teams, which should have all the competencies needed to accomplish the work without depending on others who are not part of the team. The development team model is designed to optimise flexibility, creativity and productivity.

The team lead is not so much a project manager as a facilitator and the emphasis in the team is on joint decision making. The presence of a product owner role means that there is always a user representative (at least one – remember the sharing possibility) working with the team to define needs in detail, approve ideas for the provision of features, test and confirm the quality of the developer’s work. The product owner also acts as a pipeline with the client on progress and any advice and decisions the product owner feels are needed. The team lead acts as the pipeline to the client in terms of reporting.

The team should provide its own support and version control must be considered. Version control relates to the custody of all master copies of the project’s products, and control of the receipt, identification, storage and issue of all project products. Depending on the required formality and need for configuration software, a central specialised function in the company may provide this service to all projects (see chapter 8: Change). Unless a specialised function is to be used, it will often be useful to make the team lead responsible for version control.

5.7 The product owner role

This is an Agile import. It has many benefits:

•Shorter communication lines with users.

•Access to immediate information on what the users want.

•User help in testing.

There are many other benefits. Can the product owner role make decisions and commitments? No one says the role is filled by just one person. Clearly this needs a special type of user to fulfil at least part of the client role, but the possibility is there.

5.8 Stakeholders

In this book we use the term ‘stakeholder’ several times, so it deserves a fuller explanation. The client clearly has a stake in the success of the project and is therefore a stakeholder. Other stakeholders are individuals or groups who are not part of the project team, but who may need to interact with the project or who may be affected by the project’s outcome. They may be supporters of the project or oppose it. Examples include other departments in the company, auditors, shareholders, unions, the general public and government agencies. They will require information from the project, usually progress reports, but occasionally also provide information to the project.

Apart from the client, these stakeholders are not members of the project team. They are not decisionmakers and do not commit resources.

Their information needs are covered in the Propose phase.

5.9 APM organisation for large projects

If the project is big enough to require several development teams, you may need to set up teams of the development team roles. For example, a team of all the team leads, a team of all the product owners, etc. These may only be required at the higher level of planning when dividing the forthcoming work between the development teams. These teams may need to communicate with each other to ensure the whole project is heading in the right direction and share useful information. See the proposed structure in Figure 5.5 below.

Figure 5.5: The APM organisation structure for large projects

5.10 Case study organisation

For our health and safety case study, the following organisation structure has been agreed.

⁶ www.business2community.com/strategy/structure-adaptive-organisation-0733212.