Agile Coaching Tips

Rachel Davies, Agile Experience Ltd

Introduction

An agile coach is not going to help anyone get a perfectly toned physique. We are not in the personal fitness business. An agile coach works with software development teams to help improve their effectiveness and get the benefits of applying agile principles to their work. But it is not surprising that people to get confused about what agile coaching is because the term coaching is used widely in non-software contexts, both in sports and also self-help techniques. As Tobias Mayer recently commented "Being a consultant, and adding 'Agile' in front of the term doesn't magically make one a coach. There is more to it than that."

The first value of the Agile Manifesto [1] is "Individuals and interactions over processes and tools." Skills from life-coaching can help you work with individual members of a team, to clarify personal goals and actions to achieve them. However, teamwork is at the heart of the agile development. As agile coaches, we work towards creating a focused team rather than a bunch of individuals following their own paths so we need more than life-coaching skills.

Coaches in team sports, like football, share a similar focus: building a team that performs effectively. These sports coaches 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 but techniques for building up physical sports skills don't really transfer into the world of software development.

An agile coach's domain is team collaboration and how the work is organized to create a steady stream of valuable working software. You need experience in agile software development to do this well. Then you need to learn about how to coach teams. Liz Sedley and I got together to write a practical guide "Agile Coaching" [2] to help aspiring agile coaches. Here are some of our tips that can help you be an effective agile coach.

Get Introduced

When you arrive, you may find that the team you will be coaching is not very interested in becoming agile. They have project deadlines, personal objectives, and their own tried-and-tested habits for developing software. As their agile coach, you invite them to pause and consider what agile has to offer. Often they simply want to get on with their work and don't see why they should listen to you.

How you are introduced to the team can make a big difference to their response. If you parachute into the team and say "Hi, I'm Jack. I'll be your Agile Coach." The team may be baffled about why you are there. Don't leave this to chance. If you've been brought by management, it's important that the manager takes time to shares her objectives behind bringing you in to work with the team.

However, life won't be easy if you're introduced as "This is Jack, he's an agile guru who has been brought in to tell us where you're going wrong." Avoid this scenario by letting the person who'll be introducing you know what your practical qualifications are. A better introduction might be, "I'd like you to meet Jack. The management team has brought him in because he's got six years experience in guiding agile teams through agile transitions. He's worked at Imagine Corp. Jack will be working with your team for the next couple of months to help you find ways to improve customer satisfaction and reduce defect rates."

Remember, introductions are a two way thing, make time to get to know the members of the team and their concerns.

Agile is Not a Religion

As an agile coach, you have to be passionate about the benefits that agile approaches offer. When you are excited about what agile has to offer, it is easy to come across as an evangelist who talks in a weird language full of agile buzzwords and acronyms like TDD and WIP. You may be interested in all things agile but take care not to assume the team shares the same enthusiasm.

You cannot bounce people into a change. When you spend too much time talking about the benefits of being agile, you give the impression that you have all the answers and the team has none. People will resent you pushing agile too hard. Instead, take time to understand current practice and concerns of the team before suggesting changes they can make.

Each team is a collection of unique individuals with a different set of challenges. Use specific examples in plain language rather than making broad generalisations.

You are there to help them work out what agile practices will help them solve their challenges rather than to convert them to an ideal agile process.

Demonstrate Respect

As an agile coach, you already have some experiences in how to implement agile practices. But being an expert in agile does not translate into being an expert in everything. People on the team will know more than you about the organization, the culture, and the subject domain. Respect the work that they have already done and try to tap into their experience.

Treat the team as the experts by showing that you are listening to them. You can demonstrate respect in small ways, such as asking their permission to share your own observations and by asking their opinion on ideas to improve their process. When you give respect, you earn respect from the team and they are more likely to listen to you.

You can also demonstrate respect in the way that you talk to people. When you do this consistently, you provide a role model and team members start to follow your example. Try to avoid using labels for people and grumbling about faceless departments, such as "management" or "QA". Rephrase what you want to say using people's names. For instance, instead of saying "Let's call the project manager to review the QA issues" you can say "Let's call George to review the problems Daphne's been experiencing with the new staging environment." Although doing this seems like a small thing, when you frame interactions this way, you can help break down barriers between different disciplines in the organization.

Step Back to See the Big Picture.

There's often a lot of pressure on software projects but take care not to get sucked into whatever the team is stressing about. When you get too close, it becomes harder to see what is really going on. Instead, step back to see the big picture and explore the root causes of current problems.

Although it may seem that individuals on the team are causing problems, remember that most of the time they are responding to organizational pressures. Use Systems Thinking to help find the forces at work and look for ways to influence them.

You can do this on your own but it is even better to introduce system thinking to the team. Surfacing the working assumptions of the people in the room often plays a crucial part in debugging team problems. Try drawing a diagram of effects or a force-field analysis with the team. Start by brainstorming factors at play onto sticky notes and explore relationships between them. Encourage the team to look for ways that they can change the system and make it easier to do the right thing.

Ask Questions to Spark Ideas

Believe it or not, a good agile coach avoids telling the team what to do. Instead, we ask questions to encourage the team to think for themselves. You will find that when team members come up with their own solutions, they are more likely to implement them.

Questions are a fundamental tool that in your agile coach's toolkit so it's worth learning how to ask powerful questions. However, take care not to rely too heavily on asking questions when coaching, as people can feel you are putting pressure on them to come up with all the answers rather than taking your share in problem solving.

Phrase questions carefully to avoid people feeling like they're being interrogated. When you wan to ask why someone works in a particular way, be aware that starting your questions with "Why.." can sound as if you are criticizing what was done. You can usually ask these questions differently using "How" or "What" questions. Try to ask open rather than closed questions to engage team members. You can get the team thinking by using "Thinking questions" [3] that stimulate thinking about the thinking process itself.

Have Courage

To gain the benefits of being agile, a team has to make changes. Some changes are easier to make than others. However, a team will not get the full benefit if they only do what is easy. As their agile coach, sometimes you have to ask them to face some hard truths and that takes courage.

People have a strong tendency to resist change and resist any attempts to coach them. You may be unpopular for forcing the team to face up to the consequences of their actions. Often your suggestions will fall on deaf ears, especially when the team is under a lot of pressure. Try not to take this personally, give the team a little time and then try again.

Take Time Out to Reflect

Although you may feel pressure, as the local agile expert, to come up with advice for the team, resist the urge to rush in. Take time to reflect on the situation. You can step away from the team by going for a walk or taking a break for a cup of coffee. You can even wait until the next day, when you have slept on it and allowed your subconscious to process the problem.

You may find it helpful to talk things through with someone outside the team. Sometimes you may find that the "cardboard programmer" technique effect helps. This is where simply explaining the problem to another person helps you to spot a new angle. Seek out, someone with a fresh perspective or different agile experiences help you get unstuck. Connect with other agile coaches, either inside your organization or outside (such as via an agile user group or email discussion list).

Introduce the Elephant in the Room

You may discover an issue that's holding the team back which the team doesn't talk about. As their coach, mention the issue and encourage the team to discuss if there is any action they can take to address it.

Where there is something that distracting the team focus on Agile, like job cuts, bring it up in a retrospective. Don't put pressure on the team to discuss the issue but let them know that you are aware of it and willing to talk about it. For instance, lay offs at work could be holding team back from sharing their specialist skills. Encourage the team to deal with this constructively, by considering what is still within their sphere of influence to change.

It can be much harder to deal with an issue when the team is unhappy with the behaviour of a team member. Remind people who complain about one of their team mates that there may be underlying personal issues, such as stress, ill-health or family concerns causing this. Rather than deal with this as a group in a retrospective, you probably need to initiate conversations with this person and consider talking to their line manager or HR.

Frame Change as an Experiment.

You can make change more palatable to the team by framing each change as an experiment. This helps the team to define a benefit that the team wants and engage them in constructing an approach that they will adopt for a trial period. Afterward they get to review whether they attain the desired benefit.

A simple example could be, a team doesn't have enough space in their work area to stand around their board for their daily standup. What can they try? Perhaps they can have their standup in a meeting room or maybe they can move their board. Encourage then to try one if these options then review and iterate

Each experiment is not a permanent change so it makes it easier for people to accept trying it, even team members who are sceptical about the benefits. The secret is the team is gradually getting used to making a series of small changes. Soon they may be ready to make bigger changes.

Go with the Energy of the Team

I learned this lesson from Esther Derby and Diana Larsen, authors of "Agile Retrospectives". One way to engage a team in designing their own agile process is to encourage the team to choose what they want to work on first. When you do this, the team is more likely to follow through, and early successes can build a sense of empowerment. Now, they become more interested in finding more things that they can change. Spur them on to keep the momentum going.

Summary

When you're engaged as an agile coach, you may need to educate your team and the organization about your role. Spending time with the team while they're at work is an essential part of coaching so you must insist upon this and not get fobbed off with being invited as an observer to agile meetings.

Before you start, 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. Learn about asking powerful questions and systems thinking.

If all that seems like a tall-order, start simple. Engage your current team by making its process more visible and then reflect with them on what's revealed.

References

1. Manifesto for Agile Software Development - http://www.agilemanifesto.org
2. Agile Coaching by Rachel Davies and Liz Sedley ISBN 978-1934356432
3. Quiet Leadership by David Rock ISBN 978-0060835903

---

Related Agile and Scrum articles

• Agile, Multidisciplinary Teamwork
• Adopting an Agile Method
• Creating an Agile Environment

More Agile and Scrum Knoweldge

Scrum Expert

Scrum Open Source Tools

Agile Videos And Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Winter 2009 issue of Methods & Tools