The Role of the Agile Coach

One of the new roles introduced by agile software development is that of the team coach. Until agile came along, coaches were confined to the executive suite or the sports field. As with any new role, it will take awhile before it is fully understood and scoped. Agile teams can—and do—exist without the coach role, but such teams do not necessarily achieve peak performance.

Reports from Yahoo! suggest that coaches can make a significant contribution. In this study, Scrum teams without coaching support increased their productivity by 35 percent, while those with coach support recorded 300 percent or greater improvement.

What Does a Coach Do?
For some people, the title "agile coach" is self-descriptive, but let me offer a definition: An agile coach helps a teams or individual adopt and improve agile methods and practice. A coach helps people rethink and change the way they go about development.

The coach role is part embedded trainer and part consultant—specifically, an adviser. Even the best agile training courses cannot cover every detail or eventuality a team will encounter. The coach is there to continue the training after the formal classes are over.

Having an on-site coach helps team members put their training into action. Too often, people attend training, think it’s good stuff, and then fail to incorporate their new learning into their daily work. This is particularly true when the organization sends mixed messages about change.

The coach can help teams apply agile and lean thinking to the specific environments and impediments they face. Working as an adviser, the coach can help the team adapt the methodology to their situation, and help them challenge the existing environment.

Taken together, these two sides make the coach an effective change agent—someone who is both motivating change and making it happen. That an organization is prepared to spend money on a coach demonstrates that they are serious about making change happen.

So as well as helping the team execute the agile vision, the Coach may also help motivate the team to that vision by painting a picture of how the agile world works by telling stories and providing explanations.

3 Types of Coach
While every agile coach brings their own approach to an assignment, there are, broadly, three types of coach.

The first is technical. Such a coach works mainly with those cutting code and sometimes becomes fully integrated with the developers.

Technical coaches are likely to be found pairing with developers to help them apply test-driven development, support developers in refactoring work, and help improve the continuous integration system or other activities that are close to the code.

Technical coaches are experts in what they do, and they aim to both transfer their knowledge and enthuse team members to try new approaches and techniques.

The second type of coach is also an expert who aims to transfer their knowledge. However, the focus is not on technology, but on process, management, and requirements. These coaches work with project managers, line managers, business analysts, product managers, and others who are responsible for making the work happen.

Rather than working with the code, coaching tends to happen in meetings and one-on-one sessions. There is a greater focus on facilitating events that help create change and improvement.

For example, in addition to moderating stand-up meetings and planning meetings, I normally run retrospectives and “future-spectives,” an event that applies many of the same ideas and techniques as a retrospective but is used to kick off a new project or agile transition.

When working with managers, there is more to coaching than simply knowledge transfer. It is much more about helping people rethink their assumptions and mental models. Many managers have experienced career success with other development modes, so they may perceive agile as a threat. Here, coaching gives way to the third type.

The third type of coach may work with everyone in the team, but mostly with managers and analysts. In this mode, the coach drops the expert persona and focuses instead on helping individuals and teams solve their own problems. To do this, the coach takes on a nondirective approach, declining to provide direct advice and recommendations. The coach may or may not be an expert in the field, but they assume the "coachee" is the expert, so the coach helps facilitate their learning.

The diversity of coaching roles makes it difficult for one person to fill all of them. A technical expert will find it difficult to switch to a nondirective mode, and team members may be confused when an expert starts throwing questions back at them. Even if one individual can cover all the bases on all but the smallest projects, there is unlikely to be enough time to do each role justice.

Longevity of Coaching
However a coach works, and whatever approach they take, the coach needs to avoid creating a learned dependency. This happens when the team comes to depend on the coach, and without them, the team falls back to their old ways. Coaches need to be able to withdraw when the time is right and let the team continue.

While many companies will have their own coaches on staff, and some will work with teams day in, day out for months or even years, there is a lot to be said for using external coaches and limiting the period of coaching. Internal coaches may start with the advantage of knowing the team and domain, but external coaches benefit from bringing a fresh mind and new perspective. This allows them to challenge assumptions more easily and suggest alternative approaches.

Some coaching activities, such as running retrospectives, can become stale and formulaic over time. Changing the facilitator can inject energy and new ideas.

ScrumMaster or Coach?
I am frequently asked, “What is the difference between a coach and a ScrumMaster?” Indeed, there may be very little difference if a ScrumMaster decides to play the role from a coaching perspective, but this is not always the case. Some organizations see ScrumMasters as thinly disguised project managers, and in these cases, there are several differences between coaches and ScrumMasters.

There are perhaps two main differences between a ScrumMaster and an agile coach. The ScrumMaster is tasked with ensuring the team follows the Scrum process and rules. An agile coach's remit is somewhat wider, with a greater emphasis on the change agenda.

As such, the second difference is one of duration. All Scrum teams should have a ScrumMaster who works with the team in every sprint and stays with the team for the duration of the work. An agile coach may stay with a team, but they may also move on, or they may stand back over time.

On an assignment last year I coached several teams at one company. Initially I started with some training and by walking each team through the agile ceremonies: planning, daily meetings, retrospectives, etc. As the teams became more familiar with the activities, I reduced my involvement and allowed team members to take over.

Again, this approach casts the coach as a change agent. It may be that teams need different coaches at different stages of their development: a technical coach to help the developers master test-driven development, a second coach to lead the team through early adoption, and a third to refine the processes and practices later.

Agile Is in the Changes
Much of the coach’s work is about changing individuals’ mindsets, mental models, and shortcuts they have built up over years. As my fellow coach Niels Malotaux put it recently, “Coaching is about resetting people’s intuition.”

There are hundreds, even thousands, of small decisions made every day during software development. These decisions are based on people’s mental models of how development works or doesn’t work. Part of the coach’s role is to help people unlearn many of these models and trade them for models based on agile values.

Cumulatively, these many small decisions are more important than the few big decisions made occasionally. Due to their size, you usually know when big decisions are being made, but small ones are made without thinking. It is no use switching to agile if you keep making the small decisions based on some other model.

The architect Mies van der Rohe once said, “God is in the details,” and so it is with agile. It is the small decisions that can’t be seen in advance that often derail work. It’s the coach’s job to help spot the small decisions and ensure that agile principles are applied.

Part of the reason I prefer working as a coach with a team rather than as a trainer is because you see the changes play out over time. As a trainer, yes, I deliver training, but when I’m gone, do people use it? When I’m there as a coach, I walk people through the details, and I see the change happen.

References

Rolling Out Agile in a Large Enterprise, International Conference on Software System, Hawaii, 2008

Coaching for Performance, John Whitmore, 1992

Effective Coaching, Myles Downey, 1999