2 Creating a sustainable Agile environment

“As soon as beauty is known by the world as beautiful, it becomes ugly.

As soon as virtue is being known as something good, it becomes evil.

Therefore being and non-being give birth to each other.

Difficult and easy accomplish each other. Lao Tzu”

2.1 Making and maintaining the Agile environment throughout the organization

We now understand what Agile is, and how it can benefit our organization. You are likely to be reading this publication to decide whether to start an Agile implementation in your organization, or perhaps you have already started and want to understand what is necessary to make it work in the long term.

I like to compare Agile with a sports car. A sports car looks sleek, shiny, and can go very fast. We can reach our destination sooner, and enjoy getting there. The problems come when the driver is inexperienced or reckless, overtaking when it is unsafe, cutting in at the last minute, ignoring other road users – basically flouting the rules of the road.

Good sports car drivers understand the potential dangers of driving badly; we can consider Agile in the same way. Driving a sports car well requires skill and good driving knowledge; similarly, successful Agile implementations need skill and experience at all levels. Although Agile can feel quite different, we have to create a culture that can support it but also that our organization can support. This means working in harmony within the rules of the organization, where they make sense, incorporating processes that have developed for good reasons over time, while changing those that add no value.

In order to be able to drive a sports car to its full potential there has to be a good road infrastructure, a support team to keep it in good condition, petrol stations to keep it resourced, and good planning on the part of the driver based on where they are going and why.

So, as leaders and managers responsible for implementing Agile, if we want it to be more than a passing phase we need to ensure that it will be accepted and meets the needs of the organization. Some questions to ask are:

• Does everyone understand where we are going and why?
• Are the foundations in place to enable us to get there effectively?
• Have we got the right people, who understand the methods and processes to be applied and who know the direction in which we’re heading?
• Are our supporting processes geared up to enable the Agile processes to run effectively?
• Does the whole organization understand the Agile approach and the part they play?

These points are as true for the introduction of Agile into an organization as for any initiative that uses the Agile approach. Many organizations fail to recognize this, introducing Agile into IT development teams, for example, when the wider organization does not understand how to deal with it.

This often creates a ‘corporate chasm’ where the procedures for governance and control conflict with the fast-moving, seemingly chaotic Agile world. In this chapter, I will discuss how to bridge this gap and create a new culture where Agile thrives within a suitable governance model.

2.1.1 Agile governance

In order to create an environment where you can get the best out of Agile, you will potentially need to make procedural, structural and cultural changes in the organization and in the Agile teams. Governance and other procedures within the organization must add value – if they do not, they should be investigated and possibly removed. Equally, Agile teams need to understand the limits of their authority and the rationale behind the corporate governance models, including portfolio governance. Culture is often aligned with a set of values, so it will be necessary to examine your organization’s existing value set if there is one.

As one of those responsible for making this happen, you should not be scared of this change. Many governance processes exist for good reasons, and you still need to ensure you are in control of initiatives and costs in your organization. The changes required for Agile generally put the decision-making closer to the point of impact. This does not mean all decisions are made by the Agile teams; for example, if other stakeholders not represented in the team are impacted, they need to be part of the decision.

2.2 The role of the manager

You may be reading this publication as a manager or senior leader, and wondering how to change yourself and enable your teams to work with an Agile approach. The next sections examine the changes in management approach necessary to secure a sustainable Agile environment. Such an environment requires the formation of multidisciplinary teams to work on specific goals. To a large extent, these teams are empowered to make decisions and are self-organizing, creating their own work plans and assigning their own responsibilities. In such a culture, you may well ask what your role is, and that of your manager. In fact, many of the Agile forums go as far as saying traditional managers are not required.

2.2.1 No longer managing the ‘what’

It is true that managers will have less control over what people are doing, but in a sense this has always been true in any organization that has undertaken projects or programmes. This is because the work is determined by the project and not via a management hierarchy. I would, however, argue that management, or true leadership, has never been about controlling the ‘what’. The role of true leaders is to effect change and ensure that those under their guidance have the skills, experience and motivation to carry out the tasks expected of them. They also need to ensure that individuals’ careers are progressing in a positive direction. After all, any Agile team is a transient entity. When its purpose is fulfilled, the team may well be dissolved, and its members will move on to new challenges.

2.2.2 Creating sustainable Agile teams

I have also seen a growing, but worrying, trend for Agile teams to be considered as a production line in a factory; in fact some organizations are now called ‘software factories’. In this environment, teams are assigned constantly on new deliveries of products. As soon as one set is completed, they start the next. Unlike a project environment, where this is normal for a relatively short period, the teams do not have any free time between finishing one delivery and commencing the next one. The manager must play a significant role in ensuring the health of the team, as this approach does seem rather unsustainable (paradoxically, given the Agile concept of sustainability).

2.2.3 The Agile manager

Managers who see their role as assigning and progressing the work to those reporting to them do, I believe, disappear in an Agile culture. Managers or leaders must be people who can ensure that those they manage have the necessary knowledge and skills. They also ensure people are healthy, have clear and agreed career progression, and are sustainably allocated. We will look at characteristics of good Agile managers and leaders in section 5.1. There are some specific topics that need exploring if we are to create a sustainable Agile environment.

2.2.4 Staleness in teams

A team that has worked together for a while can be high-performing and have a deep knowledge of its subject or product. However, over time, it can become stale. Team members may produce work that adds no value to the organization, see more interesting initiatives elsewhere, or reach a point where they see no innovation in what they are doing.

Moving people to new teams can remotivate them and help their career paths. Introducing new members into teams can also add insight and innovation into that area. The manager plays a vital role in understanding when this should happen. Agile approaches recommend that teams are stable as much as possible; there is a fine balance between reinvigorating teams and individuals and affecting their motivation and performance.

2.2.5 Knowledge across teams

Agile teams can become introspective; they concentrate on the goals of their initiative and often find their own ways of fulfilling them. They can ignore work done in other areas that has already solved the same problem, or even create solutions that will not actually fit into the wider organizational landscape and standards.

It is important that managers be facilitative in bringing people together, not only from different teams, but also from different initiatives and areas. This allows them to see the bigger picture, and learn from their peers in other areas.

2.2.6 Career path

Agile promotes the goals of the team over those of the individual. This works well within initiatives as it can remove potential conflicts, and ensures the job is done in the best way. However, it does to some extent ignore the needs of individuals in their own careers. It may become unclear how they can get the training they need to fulfil their ambitions, or how they can move across different teams, or even different areas of the business. Agile initiatives, and teams, are to some extent selfish, and so it is necessary to have an external view and balance on this, ensuring the individual’s needs beyond the team are actually satisfied. The manager is well placed to fulfil this role.

2.2.7 Resource management

Section 3.3 discusses the role of portfolio management in an Agile environment, and the need to prioritize initiatives based on their value to the organization, and their alignment with business strategy. Most organizations will have a finite resource. There will therefore always be a need to understand and plan the resource needs of the various initiatives.

Managers should understand the skills and knowledge of their teams and, together with the teams, participate in the process of prioritization and allocation, taking into account the needs and desires of the individuals involved. This is particularly useful for scarce resources (i.e. people with specific skills that may be needed across Agile teams). Individuals should be empowered to select their own initiatives as much as possible in this process. However, Agile will not eradicate those vital initiatives that no-one wants to work on! Agile approaches advocate that individuals are assigned to one team, full-time. Although desirable, for many reasons, this is often not possible in reality.

2.2.8 Counterbalance

Agile promotes a culture of openness, trust, collaboration and communication. When all this works well, it is powerful and the teams involved are successful. There are, however, some examples where these fundamentals were not applied. I have heard of teams where it was acceptable to give only the good news – the bad news was discouraged.

Good managers will promote relationships between themselves and those they manage. Often individuals feel they can express concerns in one-to-one meetings with managers that they cannot mention in stand-up meetings. Managers have certain responsibilities; wherever possible, they need to persuade individuals to raise issues in the right forum, such as the stand-up. Sometimes the individual has tried to do this but been ignored. This could indicate that the Agile team is not following Agile principles. The manager has a responsibility to investigate the issue as appropriate, acting as a counterbalance to the team and the initiative on which it is working.

2.3 Instilling an Agile mindset into stakeholders

I have already discussed the chasm that can be created when Agile is implemented only at one level of the organization. For it to succeed, all people in the organization need to understand how it affects them, their roles within it, and what is expected of them.

Let us examine the stakeholders in more detail to understand what it means for them to contribute to Agile initiatives.

2.3.1 Senior leaders and managers

You may be a senior leader or manager. The success of Agile in organizations will depend on your own approach and attitude to Agile, so it is important that you understand what is expected of you. This publication is aimed at giving you that understanding. Chapter 5 outlines specific characteristics and behaviours of Agile leaders. Your needs and requirements are also very important – these are discussed in Chapter 7.

2.3.2 The customer

Let us define the customer as the set of stakeholders who will either benefit from, or possibly be disrupted in some way by, an initiative. I use ‘customer’ rather than ‘user’ as it encompasses any initiative for which Agile may be used – not only IT initiatives – and it focuses on benefits realization as opposed to delivery of functionality. Customers can be either internal or external to an organization; rather than keep repeating these terms, I will refer to both types as the ‘customer’. Traditionally, customers have not been closely involved in the detail of initiatives, instead contributing at specific stages.

In an Agile approach, customers are expected to be actively involved throughout, providing resources that can be available daily and making business-related decisions. This level of involvement needs to be made clear to them, otherwise they may not be available as expected. It is important that customers are adequately trained in the Agile approach, so that they can understand it and their role within it. Some business areas may be more open to Agile, and it is better to start in those areas.

The customer needs to understand how prioritization works in Agile. Most Agile approaches work on the principle that there is a subset of the whole, often called the ‘minimum usable subset’ (MUST) or the ‘minimum viable product’ (MVP) that has to be in place in order for the initiative to succeed. Other requirements may or may not be delivered, depending on the time available. This approach requires the customer to be flexible in agreeing that not all requirements are a ‘must’. This can involve a large mind shift at first; often customers will define everything as a ‘must’. Once the initiative delivers they can see that all is well and the prioritization was correct, but initially it is often hard to convince them. There are some effective techniques to facilitate this process, such as the MoSCoW prioritization technique (see glossary).

2.3.2.1 Iterative development

The customer must understand what iterative feedback really means. It is a powerful technique for ensuring the right outcome. The continual feedback loop helps to identify the correct solution for the business need. The technique requires some care, as the customer can become confused if they are relatively new to Agile. This is discussed further in section B.2.4.

2.3.2.2 Delivering value incrementally

In order to gain value early and often, it is necessary to implement change in the organization frequently – probably more often than it is used to. As change management experts will tell us, any change causes disruption and must be managed correctly. Too much constant change may have a negative impact on the organization; too little and potential opportunities and benefits may be lost.

Depending on the size and impact of changes, customers will need to look at their own processes and procedures in their business areas, and the impact on their workforce and workload. Environments that are subject to stringent controls may need to satisfy regulators that the change has been safely applied. All of these must be taken into account when planning releases – it may not be possible to implement small changes as soon as they are ready. All stakeholders need to agree a plan that enables benefits to be realized as early as possible, while minimizing the potential extra work and disruption caused by the change. Often, opportunities to implement change may depend on business priorities and constraints. As these are not necessarily at regular intervals, regular change implementations may not be possible. The customer should be in control of this and not have releases thrust upon it.

2.3.3 The supplier

Let us define the supplier as the set of stakeholders commissioned to create all, or part, of a solution required by the customer. Suppliers can be external third parties or internal bodies. It is important that suppliers understand the Agile mindset, tools and techniques used within the organization. I have seen initiatives fail when the supplier works in more traditional ways but the organization expects and uses an Agile approach. Suppliers new to the Agile approach need training and mentoring during the first few Agile initiatives.

If the supplier is external, there may also need to be changes to the way suppliers and customers enter into contracts. This is discussed in section 8.3.

2.3.4 Operational staff

Let us now consider those responsible for the day-to-day operation of the capabilities delivered. For convenience, I will call these the operations team, although the term does not only apply to IT. To introduce Agile into an organization, representatives of the operations team need to be core team members of the programme of work. Potentially, implementation procedures and release cycles will need to change and they are the experts and owners of this process. They will understand what frequent releases are possible and the constraints and barriers that may apply.

These representatives also need to be involved in the planning, creation, and implementation cycles of the Agile initiatives themselves. Whether a solution is entirely new, or a change to an existing one, there are likely to be changes required to operational environments. These can be complex and will need thorough planning and testing, particularly in highly regulated environments. It is unrealistic to think that operations personnel can be dedicated to Agile initiatives. Firstly, the skills they bring are only required from time to time. Secondly, their key job is to maintain the availability of operational environments, and this has to be their priority. They should be involved, however, in key discussions on design and implementation. In this way there will be no unpleasant surprises when Agile initiatives introduce change into these environments.

2.3.5 Support organizations

Support organizations also need to be involved to understand the release cycles, the changes to be made and the potential impact on the user population. Support personnel will carry out reviews and testing; they will need to know the release schedules so they can plan to support the changes.

2.3.6 Quality and audit organizations

It is important that quality and audit departments understand the impact of Agile in the organization and on its standard operating procedures. Representatives should be core members of the Agile introduction programme. They can provide advice on regulatory requirements and potential changes to procedures. Early involvement will help to show that Agile is a quality-based, repeatable approach.

Quality representatives are often core team members in Agile teams, especially where quality or regulatory constraints form a major part of the project. Early involvement can avoid potential issues later, and the representatives can experience how quality is built in.

2.3.7 Finance and procurement

For Agile to work well in organizations, it is necessary to examine funding and budgeting models. Different styles of contracts and procurement may also be necessary. It is important that those responsible for finance and procurement are involved in the Agile initiative. In section 3.4, I discuss different approaches to budgeting and procurement.

2.3.8 Project, programme or portfolio management offices

Many organizations have project, programme and portfolio management offices. Traditionally, these offices have been the custodians of standards and processes, an independent auditing facility, reporting and financial support. For Agile to succeed, the new role of these offices needs to be clearly defined. Certainly, they can feel confused about how to interact with Agile initiatives, particularly given the principle of team empowerment. Some Agilistas question whether they are still required. In fact, these bodies can be very valuable to Agile initiatives, helping to define the Agile approaches to procedures defined in section 2.4 (see also The Agile PMO Pocketbook by DSDM and The Agile PMO by Michael Nir).

2.3.9 Project and programme managers and others

Agile will have a big impact on project and programme managers. I discuss this in Chapter 5.

2.3.10 Training and experience

All stakeholders need to understand Agile. On the surface, Agile can appear easy. However, it requires a different way of thinking and execution. Organizations often believe that they can successfully use Agile without training or mentoring. There are many pitfalls that the inexperienced can fall into, which could lead to early Agile initiatives failing, and consequently giving Agile a bad reputation in the organization.

It is therefore important that all stakeholders are adequately trained. For example, customers will need to understand what is expected of them, and what they can expect from Agile projects.

Training should be planned as part of the Agile introduction programme, and certainly for teams that are about to undertake Agile projects.

Experience is equally important. To use my car analogy, people who have just passed their driving test still have a lot to learn; experienced drivers understand what can happen in reality. This is also true for Agile; any Agile team should contain people who have done it before, or have access to coaches who can guide and advise the team.

Most new undertakings require a few attempts before we become adept at them. We should not expect the first few Agile initiatives to go without problems and some may even fail. In planning an Agile implementation, we need to plan for people to learn and make mistakes. Initially, choose smaller projects that add real value but are not too business-critical. If they are successful they will help the Agile cause, but little is lost if they fail.

2.4 The effect of Agile on processes and procedures

We will now examine some of the corporate processes and procedures that you will need to investigate and possibly change in order for Agile to flourish.

2.4.1 Budget management

Many of us operate on an annual budgeting cycle, where initiatives are considered based on the benefits they may bring to the organization compared with the cost and risks involved. There will be overall budget figures that the organization can sustain for the following year and some initiatives will have to be culled. Often, budgets assigned to a given initiative cannot be transferred to others without a lot of bureaucracy and effort.

The problem with this approach is that we are trying to predict what will be important in a year’s time. This does not accommodate change and is contrary to an Agile mindset. As leaders and managers, we need to understand the potential expenditure for the next financial period, but the detail is often not required. So perhaps we can set overall budgets, but introduce flexibility in how the budget will be spent. The flexibility, to some extent, needs to be across business operating units as well as those in which initiatives are undertaken, as more urgent or valuable initiatives may arise in different areas of the business. Exact alignment of budgets can be done on a more regular basis, enabling changes in the business to be incorporated, considering the business climate and priorities at that time. This helps us to benefit from opportunities that would have been missed and is discussed further in sections 3.3 and 3.4.

Having given teams their goals and a budget to achieve them, we need to empower them to take their own decisions on use of allocated budgets within the projects or programmes. With Agile planning, they will plan to deliver in time and on budget, being flexible on the scope of what is delivered. This includes incremental delivery; typically the budget assigned at any given time is less and therefore the risks of budget overruns are greatly reduced. Only in exceptional circumstances are budgets likely to be compromised; adequate exception reporting will provide the information for this. We can use entities such as the programme management office (PMO) to instigate health checks or audits if necessary.

Organizational accounting practices often capitalize initiatives once some assets have been delivered. Since Agile initiatives deliver frequently, the equivalent financial value of the delivered items can be assessed and added as capitalized assets if appropriate.

During an Agile initiative, you may decide that a sufficient amount has been delivered, or that the initiative is no longer in line with business strategy. In this case it can be closed, and unused budget should be recycled into the budget pot to be used on other initiatives. The PMO can play a role in this.

2.4.2 Processes and practices

Agile processes and practices need to be clearly defined and communicated throughout the organization, and the appropriate people trained. We can create a centre of excellence for this which will help to build up the knowledge base of how Agile is done in the organization, ensuring that the governance and regulatory requirements of the organization are covered. The centre of excellence will investigate what is required from Agile projects and programmes, always working with the principle that documentation has to add value and should not exist for its own sake. It is also the ‘go to’ source of information, guidance and training; for example, it could incorporate Agile coaches.

Although Agile is a powerful approach, it is not a silver bullet. Some initiatives are better suited to more traditional, or hybrid approaches. We need to build up the processes and practices for this hybrid world. There are checklists available for assessing the suitability or risks of using an Agile approach (for example, the ‘Project Approach Questionnaire’ contained in the DSDM Agile Project Framework Handbook) or the ‘Agilometer’ in PRINCE2 Agile.

2.4.3 Audits and health checks

The transparency and visibility inherent in Agile initiatives may make some audits and health checks unnecessary, but there are areas where such checks can add value. Audits and health checks do not concentrate on whether reports are produced at the correct time, but on ensuring that the Agile process is working properly. Specific items to check are detailed in section B.2.

2.4.4 Status reporting

The inherent collaboration in Agile and the use of highly visual techniques such as Kanban boards to communicate status will make some of the traditional reporting redundant. However, there will still be requirements for reporting to senior levels within organizations. It is important to ensure that the reports are actually required, add value and do not duplicate effort. Chapter 7 investigates reporting in more detail.

2.4.5 Resource management

Some organizations now create perpetual teams, dedicated to a specific business product. The teams consist of resources covering all required disciplines, including the relevant business area. In theory, the teams manage their own workloads, working through product backlogs (e.g. prioritized feature lists) for the specific business product. This seems to imply that resource management is no longer needed. We will discuss what is known as ‘business as usual’ in section 2.5, and this model may work in this context to some extent. However, there are three potential problems.

Firstly, it creates a limited view of the world for the team. Although the backlog is important to that particular business product, there may be more important initiatives. The model does not allow team members to be reassigned to these.

Secondly, the team will always find new items to add to the backlog, but the value they add may decrease with time. The organization is not getting appropriate value for money.

I recently attended a local government conference. One of the presenters was a product owner working on a particular local authority service. At one point, they showed the product backlog and asked for feedback. The actual users of the system did not see the value of the new items, although the product team considered them very important. The product had reached its optimum service level and the team should have been reassigned.

Thirdly, team members have little opportunity to move into other areas or for career progression. Over time, this may start to demotivate some members of the team. For these reasons, effective resource management is still needed.

Resource allocation is an interactive and iterative process, especially in an Agile environment. We want to ensure that all required resources will be available to work on an initiative at the same time. This will require involvement of resource managers from different areas of the organization – there is no point in assigning supplier resources in May if the customer cannot provide resources until October. It is therefore important to have regular reviews of the portfolio priorities and the resources allocation.

There are some other areas where resource management differs in Agile environments. These are discussed in section 6.2.

2.5 Business as usual

Business as usual (BAU) is a relatively common term in Agile circles. It is mainly applied in the IT sphere, and tends to relate to work defined as ‘maintenance’ or ‘support’. That is, it deals with changes to existing systems.

The concept is that the list of changes (and potentially issues) can be collected in a backlog (known as a product backlog in Scrum), then the team will prioritize and work through the list in short timeboxes (known as sprints in Scrum). Techniques such as Kanban can also be used for visualizing current status and helping to smooth the flow.

Some proponents suggest that this approach eliminates the need for projects as they can be seen as ‘large’ changes that are added to the BAU backlog. Although this approach can be effective, there are a number of considerations, some of which have already been covered. The key one is how the changes are measured against the other initiatives that could be undertaken, in terms of value to the organization.

2.6 Individuals and interactions

2.6.1 Communications

Insufficient communication is often cited as one of the main reasons for failure of initiatives in organizations. Issues range from misunderstanding what is required through to stakeholders not understanding what we are trying to achieve, the status and when it will deliver.

Communication is at the heart of the Agile approach, as stated in the Agile Manifesto principle ‘Individuals and interactions over processes and tools’ (see section 1.2). To get the most out of Agile, you will need to examine how your business is organized, structurally and logistically. I am often asked, for example, what happens when teams cannot be co-located. Also, if there are multiple teams and larger, scaled projects, how is communication facilitated? The following sections aim to provide some guidance on this.

2.6.1.1 Co-location

At the team level, all relevant stakeholders are part of the team and communication naturally occurs between members. Often, the team is co-located and the team room walls are covered with information. Questions can be answered and problems resolved quickly. Co-location also helps to bind the team together. The members are there for a common purpose and any previous differences or contentions soon disappear as they get to know each other. The inability to co-locate is often seen as an argument for not taking an Agile approach. Co-location can be difficult in situations where customers are distributed worldwide, or supplier teams are located elsewhere, whether in the same organization or a separate organization as part of outsourcing.

The Agile approach can work well when teams are in different locations and this is probably less risky than taking a traditional approach. Communication tools are available that enable teams to have virtual stand-ups, using videoconferencing if necessary. Email, virtual whiteboards and chat rooms can also facilitate ad hoc conversations.

However, innovation often happens around coffee machines, in lifts, in the car park. These meetings are not planned, but can move the team into new directions not previously considered. There are now tools that offer ‘virtual coffee machines’. As individuals see people entering the virtual coffee room, they can join in. It is not only a chance to interact socially, but also to have new ideas. If you operate distributed teams, I recommend you investigate these tools and other ways of facilitating ad hoc communication.

Teams still need to meet face to face occasionally, however. This time allows individuals to get to know each other, have a drink together, understand the problem they are trying to solve, and resolve any differences that may be building. Although meetings may be seen as expensive, their value outweighs the expense as they will remove barriers and aid real understanding. They can be planned at the start of increments, or at key points within increments, and help to set the team on the same path.

2.6.1.2 Working in distributed teams

Many organizations have chosen to outsource certain areas, including development, to teams in separate companies, often with very different cultures. Sometimes projects are outsourced to third parties, where their offices can be located some distance from the customer.

In this situation it can be difficult for the customer and the supplier to have sufficient access to each other. This can lead to misunderstandings and consequently the wrong solution being developed. A few years ago I was part of an outsourcing working group for the DSDM Consortium, and we concluded that an effective solution to these problems was to introduce so-called ‘ambassador’ roles into teams. A representative of the customer frequently visits the supplier site, and is the key point of contact for the development team. Also, and equally as important, a representative of the supplier team frequently visits the customer site to resolve potential misunderstandings and communicate real situations to the development team. Figure 2.1 shows an example of a distributed Agile team model.

As well as providing a conduit to communication, these representatives are cultural ambassadors. Distance can create contention between teams – each using terms such as ‘us’ and ‘them’. The on-site ambassadors are the human face of the team, and it becomes clear that we are all just people doing the best we can.

2.6.1.3 Communication on a large scale

When we consider Agile on a large scale with multiple teams, clear and continual communication is vital. It is important to create formal communication plans to understand how various stakeholders will be kept up to date. However, it is important that the teams understand the whole picture and also know what other teams are doing.

There is much talk of ‘scaling up’ Agile. Techniques used on a small scale are scaled up and expected to work just as well. However, often things cannot be scaled up; structures simply cannot be supported on a large scale. This is seen in engineering, in organizational structures, in building and even in IT where a solution that works very well with small amounts of data and/or users suddenly collapses when scaled up. I would spend three weeks in each city. This approach worked very well: the team in city A had day-to-day contact with the customer and could pass on the current status, particularly the political status (how the customer was feeling). I was the ‘glue’ between the teams, being able to see potential conflicts and overlaps between teams and helping them to resolve them. The teams could communicate via a form of instant messaging and stand-up calls via teleconferencing.

An example of a small-scale technique for communication is the stand-up meeting, or Scrum. Theoretically, on a large scale teams choose representatives to attend stand-ups including those from other teams. Teams can discuss progress, cross-team issues and interdependencies. These meetings can be useful, but they commit resources to more meetings. Some team representatives may find that there is no point attending as there is little or no interface between the teams.

A different approach may be more effective. Using the principles of accountability and responsibility, all stakeholders take responsibility for:

• Being aware of the progress and issues of other projects and teams
• Providing their own progress information to other teams, including current problems and issues
• Identifying potential technical or business inconsistencies and escalating them.

Project- and programme-level roles become important for large projects and programmes with multiple teams. These are discussed in Chapter 5. With respect to communication, we all have a responsibility to keep up to date with teams even if we are senior managers. Some aspects of this are:

• Regular visits to Agile team rooms without interfering with the teams
• Attending stand-up meetings as an observer
• Identifying teams that they may need to bring together to resolve potential problems
• Ensuring that all cross-team information is clearly communicated to all teams.

In this way, teams can come together as and when issues are identified. This eliminates the waste caused by having too many meetings, and is more effective. Teams that are working on closely related features may find it beneficial to meet together frequently; others just keep appropriate colleagues informed of progress.

There will still be times when bringing all teams together is important – for example, when an initiative or an increment starts. This builds team understanding and is also an opportunity for everyone to interact both with respect to the initiative and socially.

The information communicated on a small scale is probably not required at the higher level; a more aggregated view may be more appropriate. For example, an individual team will be interested in the status of a low-level feature within the current sprint. The organization is probably only interested in when the high-level item will become available, and this information is aggregated across teams. This is discussed more in Chapter 7.

2.6.2 Empowerment, the team and the individual

The principle of empowerment is an important concept in Agile. Arguably, Agile approaches cannot operate without it. At various points I have discussed moving decision-making to the point of impact, and the trust and openness required for this to happen. This may be a cultural shift in your organization. There is an interesting consequence to this, however. By empowering teams and individuals we are requiring them to make decisions and to operate to a large extent without supervision. This can be as much a cultural shift for them as for the managers. We ask teams to experiment, to think of and prioritize work, to be self-organizing. We tell them it is acceptable to fail. If they have been used to a culture where these things are not acceptable, they will need reassurance that it is safe to operate in this way, and that there will be no personal repercussions.

As with any change, teams and individuals need to be led through the change. You need to provide them with safe environments and ensure that they understand what this means. Teams have to be given time to adjust, and to build trust in the new ways of working.

You may need to guide them through the change before they feel comfortable making their own decisions and using their own judgement. Workshops can be very effective for facilitating teams to be self-sufficient. A certain leadership style is also required – managers should not immediately answer any questions or queries but make it clear that they expect the teams or individuals to present solutions.

Another aspect of empowerment that can be confusing for teams is understanding what they are empowered to make decisions on. The boundaries need to be clear, otherwise too many decisions may be pushed upwards or decisions may be made by the team that have a wider impact and need other stakeholders to agree to them. Even worse, decisions may not be made at all. A good, well communicated governance and decision-making framework will help to resolve some of these issues. This is discussed in Chapter 3. The teams will gradually understand the empowerment levels and, with time, it will become a natural process.

For team empowerment to work effectively, the team needs to operate in a ‘no-blame’ culture. This means the team collectively celebrates success and also accepts failure. At the same time, individuals are personally accountable and responsible. Each member of the team has to pull their weight and do the best job they can. The team will quickly weed out those who are not doing this.

2.6.3 The ‘haves’ and the ‘have nots’

When Agile is implemented in organizations, it often starts with a few teams. For those outside of the teams, it can sometimes feel as though the Agile teams are having all the fun, gaining recognition and being motivated. As well as possibly causing contentions within the organization, this can be demotivating for those not involved. In fact, those excluded can sometimes become the worst critics of the Agile approach.

Change management plans for the Agile implementation should take this into account, and ensure that everyone understands the full plan and their part within it.