Agile Coach: Understanding The Role

Independent agile coach Rachel Davies examines the role of the agile coach.

When I tell someone who hasn’t heard about agile software
development that I work as an Agile Coach, they often assume that I
work in physical fitness industry. Sadly, an agile coach is not
going to help you get a washboard stomach! We work with software
development teams to help them improve their performance and get
the benefits of applying agile principles to their work.

I’ve worked as an agile coach for seven years now and still find
that the role is not widely understood in the software industry. I
hooked up with Liz Sedley to get more information out there about
the role, the result is the first book on “Agile Coaching.” Let’s
explore here what an agile coach does and why this role is so
crucial to succeeding with Agile.

Becoming an agile coach

Once upon a time, I was a software developer immersed in my own
little world of software architecture and design. I was often
oblivious to what my colleagues were working on until we attempted
to integrate our work, and then entered a world of pain. How could
we work more effectively to avoid interminable periods of rework?
Luckily, I came across Extreme Programming (XP) in 2000. When you
first hear about the practices of XP it sounds crazy; developers
write tests before coding, they program in pairs, plan using index
cards, and integrate software continuously. I joined an XP team to
find out if this could really work. I was delighted to find that
delivering software iteratively and working in closer collaboration
makes the work more enjoyable as we learn together.

XP includes the role of Coach who, according to Kent Beck,
“watches the process as a whole and calls the team’s attention to
impending problems or opportunities for improvement.” After three
years working as a developer on an XP team, I chose to branch out
and find work as an independent XP Coach. I was able to help teams
get started with XP practices by drawing on my experience of
implementing practices such as test-driven development and planning
with user stories. Nowadays, I’ve broadened out and help teams use
techniques from a wider set of Agile methods than XP. I won’t dwell
on the pros and cons of Agile methodology here.

However, I have learned that being a coach requires more than
experience with agile practice. A coach helps a team implement
changes and work more collaboratively, which can be a slow process
because most people don’t like to change how they work. For this a
coach must understand how to influence people and manage
organisational change.

Contrasting agile coaching with existing
roles

In a nutshell, an agile coach helps teams grow strong in
applying Agile practice to their work. It takes time to
adopt these changes so you can’t do this effectively as a “seagull
consultant” or trainer who swoops in to deliver words of wisdom and
then makes a sharp exit. You need to spend time with a team to help
them to become more aware of their workflow and how to collaborate
effectively.

How is being a coach different from a team lead or project
manager job role? Well, it’s not incompatible. The difference is
that these roles have a wider set of project and company specific
responsibilities, such as reporting progress, performance
appraisals, etc. I notice that the pressure to deliver can distract
from a focus on process improvement. Whereas, if you work solely as
an agile coach, you can make this your sole focus because you don’t
have responsibility for project deliverables and administriva.

Being a coach is also different because it’s a transitory role
not tied into project duration. Your goal is for the team to become
self-coaching and adept in applying agile then you move on. That
doesn’t limit agile coaches to introducing agile into organizations
and establishing new agile teams. The majority of the teams that I
coach are already applying agile techniques and seek coaching
because they want to boost their performance and proficiency in
agile software development.

Drawing from other coaching fields

You can see why people get confused about what agile coaching is
because the term coaching is used more widely in non-software
contexts. For instance, you may associate coaching with sports and
also self-help techniques. Let’s take a closer look at how these
overlap with agile coaching.

Business and life coaches usually work with individuals on a
one-to-one basis. They help their “coachees” uncover personal goals
and work out how to achieve them. As an agile coach, your primary
focus is team performance towards company goals rather than the
personal growth of individual team members. Of course, you’ll find
that you often have to work with individuals to improve teamwork.
So you can draw on techniques from lifecoaching to help people gain
perspective on their work and open their eyes to new possibilities.
However, I’d say that life-coaching skills are not sufficient. An
agile coach has to bring a broader set of skills to a software
development team than simply clarifying goals and working out
required actions to achieve them.

Sports coaches share the same focus of building a team that
performs effectively. They require a deep knowledge of their sport
and are often former players. They work on skills, tactics, and
motivation. An agile coach wants to help teams with the same things
— although techniques for building up physical sports skills don’t
really transfer into the world of software development. Instead,
you can encourage developers on your team to improve as craftsmen
and practice their code kata through coaching dojos. So we see an
agile coach can draw from both these coaching fields.

Understanding core skills

The core skills for coaching agile teams are solid communication
skills, such as listening, asking questions and giving
feedback.

To engage with the whole team, you must go beyond one-to-one
conversations and enable effective team conversations. So meeting
design and facilitation are also core skills for agile coaches.
This year I’ve run workshops with coaches at Agile and XP
conferences to introduce Richard Hackman’s model for coaching
interventions. He defines a coaching intervention as “any
action that seeks to minimize process losses or to foster process
gains.” He goes on to identify three categories of coaching
intervention:

• Educational interventions improve understanding and skills on
the team.

• Consultative interventions foster process improvement by
helping the team become more aware of their (mindless) habits.

The big eye-opener for most agile coaches, who took part in
these workshops, is that they usually focus on educating teams in
agile practices and how to improve their agile process but they
neglect motivation. Notice where team members are coasting along
and not pulling their weight, now explore why. Think about ways
that you can re-engage each team member. You can make a start by
bringing them together to establish shared goals that they believe
are achievable and open up team discussion of what’s in it for
them.

Where software design experience helps

You might be surprised to learn that many of the skills that we
acquire as a software developers also come in handy as coaches.
Much of our work is to help teams “debug” their agile process by
making them more visible and inspecting what’s revealed. We follow
the work through the team from concept to delivery and help the
team to become more aware of inputs and outputs along the way. We
prompt them to get their brains in gear and find ways they can
adapt their processes to raise and handle exceptions smoothly.

Object-oriented thinking also helps us see opportunities for
refactoring team process. Our team needs to get the coupling and
cohesion of the work right to improve the flow of software
deliveries through the team. Many activities in the Agile lifecycle
can be decoupled. For example, a planning meeting can be broken
into different sections that are run as separate meetings; doing
this helps keeps the meetings shorter and more focussed.

We can also apply the Once-And-Only-Once principle to remove
duplication of information which when spread around a plethora of
tools (such as wikis, defect tracker, index cards, spreadsheets)
can be a source of confusion and lead to important aspects of
requirements being missed. When you make the right information easy
to find then decisions can be made swiftly by the team.

Bringing it all together

When you’re engaged as an agile coach, don’t be surprised if
your clients have some strange ideas about what an agile coach
does. They may expect all coaching to happen in a series of
meetings far away from the team. You’ll need to educate them about
the role and explain that spending time with the team while they’re
at work is an essential part of coaching.

Before you get started, hone your communications skills for
one-to-one conversations and team meetings. Draw from the fields of
life-coaching and sports coaching for ways to unleash intrinsic
motivation. Now you can apply your existing experience in software
development, to lead teams to debug and refactor their agile
process. If all that seems like a tall-order, start simple. Engage
your current team by making their process more visible and then
reflect with them on what’s revealed.

Rachel Davies works in the UK as an independent agile coach helping teams adopt and improve their agile delivery capability. Her new book “Agile Coaching” shares many practical tips that can help you take your teams to the next level. Rachel has supported the agile community as a former chair of the Agile Alliance and as an organizer of many Agile conferences. This year she is the general chair for XP2011 conference in Madrid. Find out more information from her website at http://www.agilexp.com and follow her blog at http://agilecoach.typepad.com/