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.
• Motivational interventions improve effort by building shared commitment and minimizing free-riding.
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.