5 Directing Agile initiatives

“Ruling a great nation is like frying small fish.

When they are overstirred, they will break into pieces. Lao Tzu”

Although empowerment is an important part of the Agile approach, we still need good leadership. Teams can go off track, initiatives can stall, and the reasons for doing them can change. Just because we are using Agile techniques does not mean we don’t need common sense. Our intuition and senses are still valid – if we think something is going wrong, it probably is.

In Agile, there is a delicate balance between adequate control, understanding and tracking, and the necessary team empowerment and trust to deliver.

5.1 Good Agile leadership

Whether we are Agile leaders ourselves, or choosing the right people to run initiatives, there are certain characteristics we should be looking for, many of which are standard for leaders in any organization today. Individuals without these may not be suitable leaders within Agile. In essence, leaders need to be able to inspire the teams to fulfil a vision by gentle steering and in small steps, empowering them to deliver the best outcome and dealing with problems and issues (often called ‘impediments’ in Agile) along the way. The characteristics of good Agile leaders are described in the following sections.

5.1.1 Strong communication skills

Leaders need to be able to get their messages and visions across clearly so that everyone understands them. They must also be able to relate to individuals so that they can inspire them and build trust. Techniques explained in the theory of neuro-linguistic programming (NLP) may be also useful in establishing empathetic relationships with teams and individuals (see Bavister and Vickers, 2014).

5.1.2 Confidence and trust in their teams, giving them real empowerment

Agile requires teams to be left to get on with things as long as they are working within the defined empowerment limits. Leaders have to trust that they will deliver. At the same time, particularly with new teams, leaders must help them to understand their empowerment while bringing them back on course if they start to stray too far.

5.1.3 Clarity of vision, ability to share it with others and determination to achieve it

In the fast-moving, iterative world of Agile, it is easy to be distracted and lose vision of the overall direction. To avoid this, leaders need to keep a strong focus on the end goal and be able to communicate it clearly. This is important since the overall initiative is being achieved in small steps. Although Agile makes its achievement easier, at times it will be challenging or challenged, and leaders need to be determined to make it a reality. There are many examples where such determination has changed the world.

5.1.3.1 Strong focus on priorities

Agile works because it concentrates on those things that will give real benefits to the organization as early as possible. This implies that priorities must be clear. Agile leaders will be able to understand the priorities and remain focused, without unnecessary distractions.

5.1.3.2 Respect for everyone involved in the initiative

The good Agile leader will understand that everyone has a key role to play in the achievement of the vision, and each deserves as much respect as any other team member. Respect breeds motivation and trust, and the result will be a high-quality outcome.

5.1.3.3 Ability to inspire and motivate

Teams work at their best if they believe in what they are doing and are highly motivated to achieve it. True leaders can build this into teams and individuals.

5.1.3.4 Ability to drive, inspire and embrace change

Change is key and inevitable in Agile initiatives. Good leaders will be open-minded, and accept that change will happen; they will also instigate change as they see necessary.

5.1.3.5 Passion and pride in what they do

Figureheads are sometimes incorrectly chosen for projects and programmes purely because of their position or reputation. A leader needs to show passion and pride; choosing people in important roles who are committed to the change and understand the benefits will help to ensure this is instilled in the team.

5.1.3.6 Willingness to take calculated risks

In my experience, the old sayings ‘nothing ventured, nothing gained’ and ‘fortune favours the brave’ have proved to be true. Many of my best experiences, and much of my growth as an individual, have come when I have stepped outside my comfort zone and taken calculated risks.

5.1.3.7 Servant leaders

Many Agile thinkers talk of the concept of the ‘servant leader’. In fact, this is an ancient concept, dating back to 600 BCE. In essence, it means the priority is to encourage, support, and enable teams to realize their full potential and abilities. This implies that they will delegate responsibility and engage in participative decision-making.

There are various translations of the Tao Te Ching by Lao Tzu from the sixth century BCE. Chapter 17, paraphrased, says:

“The best ruler is one whom the people barely know exist. Next comes one whom they love and praise. Next comes one whom they fear. Next comes one whom they despise and defy.”

I interpret this to mean that you get better results if you leave people to get on with things! It is a subtle form of leadership, and can be confused with being irrelevant, as on a day-today basis, it may not be clear what such leaders do. Their value becomes apparent in their absence; suddenly things start going wrong, or the focus of teams may suffer. Project managers make good servant leaders. The value of good project managers is often not recognized until they are not there and the project starts to go wrong. This had led to some misunderstanding in the Agile community as to whether project managers are needed.

5.1.3.8 Understanding their own accountability and responsibility

Delegation to teams and their empowerment do not mean that leaders can be free of accountability and responsibility. Ultimately the phrase ‘the buck stops here’ still applies, and the teams will understand this and respect leaders who live up to their responsibilities. Agile teams can seem to be a no-go zone for leaders, with teams saying they want to get on with it. Good leaders will innately understand when to be hands-off, and when to intervene. The signs can be subtle, but will be there if the leaders understand the teams sufficiently well.

5.2 Managing the Agile team

Team-level structures are well defined in Agile. Teams encompass all aspects of the job to be done, incorporating business, technical, operational, supporting and specialist roles (see Figure 1.3). Depending on the method, little distinction is made between the team members as it is the responsibility of the team as a whole to deliver the required outcomes, rather than the individuals within it. In this respect, the team is self-governing, although normally one of the team either emerges or is allocated to ensure that the outcomes are made a reality.

In Scrum, for example, the Scrum master is responsible for facilitating the team to its outcome, removing impediments and helping to resolve issues. In DSDM, this role is fulfilled by the team leader. Both are transitory roles that can change from timebox to timebox.

Similarly, the product owner has the power to make decisions on the features that are to be part of the product or capability being developed. Some in the Agile community argue that nothing else is required to develop successful initiatives. This can be true where the initiative is small and there is only one team. As many organizations have discovered, however, this simple model becomes insufficient for large or complex initiatives. These can be categorized in two ways:

• Multiple teams are needed to produce the capability
• The development is only part of a wider initiative that involves many different organizational aspects.

In the first case, there needs to be coordination and consistency across teams, especially ensuring that each team understands the technical landscape in which it needs to work, and the limits of its scope, so as not to encroach on other teams’ work and to ensure consistency. Although, to a certain extent, the teams can be self-organizing and resolve these issues among themselves, having roles that enable an understanding of the whole picture and enable judgements or arbitrations to be made in this area will ensure the smooth running of the Agile initiative. Additionally, some upfront work may be necessary at the start of the initiative to be clear about what teams are needed, and how the capability can be partitioned into discrete parts that can be delivered by the different teams.

In the second case, there are many other activities that have to be carried out – for example, changing business processes, updating technical infrastructures, modifying organizational units, preparing for the capability, and investigating multiple locations. All of these require coordination, political sensitivity, organizational capability and a good grasp of the whole picture. It is both unreasonable and unfeasible to expect individual teams to be able to do this. Therefore, when we consider role structures for Agile initiatives, we should take this into account. The DSDM model is a good example, defining a complete set of Agile roles at all levels. There are other Agile methods that work at this level, such as PRINCE2 Agile, SAFe, and LeSS. At the project level, DSDM identifies a role model as in Figure 5.1.

The project level described in Figure 5.1 provides the coordination and steering roles across teams, and in all aspects of the Agile initiatives. The project level within this model solves a fundamental issue with the concept of the Scrum product owner. A product owner is meant to be senior enough to make critical high-level business decisions while having the time and opportunity to be available for development teams for a lot of the time. The DSDM model defines two aspects of the role – the business visionary who understands the high-level objectives for the capability or product and has the power to make it happen, and the business ambassador, who understands detailed aspects, and can interact on a daily basis. The business ambassador can make most of the decisions, escalating to the business visionary any issues that change the scope or direction at a high level. Often in organizations, those who can assign budget and resources are different from product owners. The model allows for this, with the role of business sponsor, although the roles can be combined if this is not the case.

The project manager is the ‘glue’ between teams, helping to resolve inter-team issues and ensuring that all teams move towards the high-level destination. They also interact with the wider community and senior stakeholders, consolidating information into a format that works for them.

The technical coordinator looks after the overall technical architecture, and ensures that it remains sound across teams, while allowing innovation within teams.

As a team, the project level can act as governance for Agile projects and as the interface to corporate governance processes. Taking the principles defined in Chapter 3, they provide gentle steering and governance to ensure that the project will meet its objectives, while empowering the teams to deliver. They can also help to resolve cross-team issues, liaise with senior and difficult stakeholders, and provide an overall view of the project.

It would be incorrect to equate these roles directly with similar ones defined in more traditional approaches. The roles are proactive and not just figureheads. They are also facilitative and not ‘command and control’. Once the overall objectives are clear, teams must be trusted and empowered to deliver against them. Intervention is only necessary if these objectives are in jeopardy or if the business changes such that the current direction is no longer appropriate.

5.2.1 Agile programme structure

Can Agile be used for programmes of work that cross many disciplines, potentially take many years and introduce major change into an organization? Yes: the project role model can be expanded easily to cover programmes. The model from DSDM’s AgilePgM Agile Programme Management Handbook (2014) is a good example. LeSS and SAFe have similar models. Figure 5.2 shows the programme role model.

At this level, the project teams will be running the projects and activities to introduce capabilities into the organization. The programme team provides the ‘glue’ throughout the programme in a similar way to the project level in projects. Once agreed, projects are autonomous, but the project-level roles should be undertaken by the appropriate people from the programme level. This avoids too much governance and potential delays as there is no requirement to escalate from project level to programme level.

5.2.2 Summary of roles

Table 5.1 gives a brief summary of the roles that can exist in an Agile environment to ensure appropriate governance.

5.3 Risk management

Risk management is as important in Agile approaches as in any other. Standard risk management techniques should still apply. These will include processes for identification and analysis of risks, as well as proposed mitigation plans, which either reduce the risk or are enforceable should the risk become a reality. Adequate time and resource should be applied to managing risks, and some of the mitigations may become part of the product backlog if the risk is seen to be very high.

Agile approaches can both reduce risk and introduce new risks based on which approach is used. These are discussed in Appendix B.

5.4 Incremental delivery of value

One of the key points of the Agile way of working is the ability to deliver value early and often to the organization. Often, however, Agile initiatives concentrate on delivering discrete components that in themselves will not deliver value. It is only when the organization has modified its ways of working, and changed business processes and organizational structures, that the benefits start to be realized. This is not helped by the Agile Manifesto principle ‘Working software over comprehensive documentation’. I believe this should really read ‘Delivering value over comprehensive documentation’. Otherwise, when Agile is applied to IT, users receive pieces of software which are useful to them, but do not add value as nothing else changes to give that value. Good benefits management and planning will help to achieve this, and is discussed further in section 8.2.

5.5 Retrospectives and continual improvement

Continual improvement is a central theme in Agile, and iterative development is based on it. The solution is constantly reviewed and updated until it reaches a point when it is good enough. Even after this, feedback from live use will improve it further.

The other aspect of continual improvement is for the people and processes involved. The general tool used in Agile for this is the retrospective. At key points the team will get together to review the last period and determine ways to improve in the future. Themes can range from processes used to team interactions. The principles of honesty, no-blame and transparency are important themes in the retrospectives, and within these themes we aim to answer the following questions:

• What should we stop doing, because it doesn’t work as we thought?
• What should we continue to do because it works really well?
• What should we start doing as it will improve our working situation?

This is similar to the traditional ‘lessons learnt’ process. However, it is driven by the team involved in the retrospective itself. I suggest further reading on retrospectives to get the most from them (Derby and Larsen, 2006; Gonçalves and Linders, 2014).

Scrum recommends retrospectives following every sprint, which could be as often as every two weeks. Many teams complain that retrospectives happen too often and are too time-consuming. I believe we need to use common sense: if everything is going well, a brief, informal discussion may suffice. If there seem to be problems – at any time and not just at the end of a sprint – a more formal retrospective can be arranged.

Be careful, however, as there may be issues that will only emerge in formal meetings. Even with the principles of honesty, no-blame and transparency, some people will bottle things up and only talk about them in a formal situation. This can be even more apparent when different cultures are involved. The important thing is that the retrospective only exists to aid continual improvement – it should not become a meeting for meeting’s sake.