I’ve been involved in agile coaching for several years but I’m seeing a trend of people totally misunderstanding the role of an agile coach versus that of an agile trainer. In fact, I’ve written about agile coaching  and , and even Bob Galen, Velocity Partners’ previous Agile Evangelist, wrote it about it multiple times including one main article here. So why is there so much confusion? Because I think people have an expectation about coaching – especially agile coaching – that simply isn’t true. So let’s talk about agile coaching, shall we?

An Agile Coaching Summary

So let’s start with the basics. What IS agile coaching?

The simple answer is that an agile coach works with a team to understand what they do, what they don’t do, and how they might be able to improve. An agile team needs to find their own way forward but a coach can help provide some possibilities. They have experience with agile, with methodologies, and have hopefully “been there, done that, and gotten the t-shirt”.

The best agile coaches I know – and it should be every coach – don’t solve the team’s problems – ever. Instead, they focus on asking the questions that teams need to here. A good reference for the kinds of questions a coach should ask is ‘ Powerful Questions. I’m pretty sure Lennie is working on a book about them, but in the short-term, he’s written an that helps describe some of the thinking. Then there is the “Bible” of agile coaching: Lyssa Adkins’ .

Agile coaching involves a lot of observation. I’ve seen a lot of coaches that focus only on the ceremonies. If you’re a remote coach, this is often the only thing you can do although. But many teams have great ceremonies. They say all the right things. They do all the right things. And then they go back to their desks, put on their headphones, and disconnect completely. I call this “not being a team but a bunch of different people working on the same thing”.

Agile Training

Agile training, on the other hand, is telling people what to do and why. When we give training, it’s to explain the best practices and reasons behind a particular framework or methodology. Training can cover a lot of aspects, including the roles and the responsibilities of those roles. The most obvious are the classes taught by Scrum Alliance CSTs (Certified Scrum Trainers) who teach the Scrum Master and Product Owner classes.

When we teach training classes, we are telling people how to do something. We’re providing a strong recommendation (at least) and (possibly) actual requirements. In a Scrum Master class, you should be learning about Scrum, first and foremost, but also about how Scrum teams operate, how to measure their progress, and how to take those first stumbling steps toward coaching your teams. We (unrealistically, I think) expect newly-minted Scrum Masters to come back to their teams and be effective. It will take quite some time before your Scrum Master can fully become the master part of that moniker. The trouble with training is that once you’re done, you should have enough information to be successful. With agile, though, the challenge comes not from doing it but from what you do when you’re not doing it. And that’s where coaching is really beneficial.

What’s Confusing?

I honestly think it’s just an expectation about what a coach is. Batting coaches don’t teach a ballplayer how to swing the bat. They provide insights to the batter about their stance, how they hold their hands on the bat, bat speed, position, and a myriad other things. But “swinging a bat” isn’t one of them. It’s incumbent on coaches to establish a working agreement between themselves and the team. In one recent case, I utterly failed to do that and a lot of misconceptions and misunderstandings resulted.

There is no reason to expect that a coach will come in and fix all of your problems – not even trainers can do that. But a coach can – and should – provide some input about what you’re doing well, where you can improve, and how you can implement some of those changes. It’s all about open lines of communication and feedback. Without those, any relationship is doomed.

@ Velocity

I’ve had a few engagements here at Velocity Partners and some of gone exceptionally well and some (well, one) has gone very poorly. In every engagement, there’s the opportunity for learning, but we learn the most when we fail. I’ve learned a lot from that experience and will work diligently to make sure that I make the changes to improve myself as a professional and as a coach.

We have two coaches on staff at present, each with a different focus but both have the same goal – to help teams be the best they can be. Sometimes that may require a slightly firmer hand but I prefer a lighter touch where possible. I’m still learning some of the ins-and-outs of the relationships here, but coaching is critical to our success and it’s incumbent on me and the other coach – Adrian – to be the best coaches we can be for our teams.

Closing Thoughts

Coaching is both a science and an art. There are parts that rely on the techniques, the training, and the methodology and framework. And there are parts that rely on the interpersonal relationships, the communication, the intuition, and the experience of the coach. I find that I excel at being able to communicate difficult concepts to people in terms they can understand. I can translate, if you will, from “agile” to “<common frame of reference>”. It comes from having a lot of experience in agile in different roles but also in having a breadth of interests. I played baseball. I was in a band. I was a software engineer. And so on. All of those things have given me some level of understanding about a lot of different topics and I can leverage that when teaching and coaching.

In all cases, make sure you’re focusing on what makes sense for the team and letting them know what you’re doing. If you keep those lines of communication open and establish and revisit your engagement working agreements you’re going to be successful.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)