Agile Coaching [Rachel Davies, Liz Sedley]

Hey friends,

As a consultant, the biggest part of my job is dealing with people. I read Agile Coaching (http://www.amazon.com/Agile-Coaching-Rachel-Davies/dp/1934356433) willing to discover techniques to get the best out of my teammates, and also to help me to introduce new ideas organically, without forcing them down on the team. With the perfect team, I’m sure everyone would be self sufficient and would try to understand the context to then try to improve it; however, in reality, most of the times people are blinded by their beliefs and need a little push to go forward.

Even though the book is very basic in many senses (most of it feels like a review of fundamental concepts that I would expect the reader to already know), there are quite useful parts where the authors share their own experiences dealing with the implementation of agile practices in non-agile teams. They present situations that I face often and it is interesting to see how they dealt with it and what was the outcome. Besides that, there are good tips that are useful for any consultant.

A very good point that is made throughout the whole book is that a coach should not solve problems for the team, at least not hands-on. As the authors say, it is hard to make the shift to giving advice rather than playing an active role in getting the work done. This is something I struggle with often, facing situations that I know I can solve, at the same time when I’m trying to push the team to solve it by themselves. It’s hard to find the balance and I believe that it comes with experience. Paulo Caroli[1] once told me “ideally, the team won’t even notice I’m here. If it comes the time when people have to seek for my help proactively, then there’s something wrong”. I believe it relates to this.

Another skill that needs attention when dealing with any team mate is the ability to listen. I noticed that it is not only important because, well, you have to pay attention to what people are saying anyway, but also because it helps to build a stronger relationship within the team. When you show you care about what your peers are saying, it’s likely they’ll start to trust you. Making people feel comfortable to talk about the problems they’re facing is fundamental so that a coach can help them. A good technique to achieve this is asking open-ended questions – “What were you trying to do?” sounds much less accusing than “Why did you do that?”.

A coach must also be able to deal with conflicts. I’ve seen many agile teams joining projects in which people have been working on for a while already, and then pointing what should be improved and how (“Oh my god, I can’t believe you guys are not pairing, not doing TDD and not following the As A … I want to … So that … format!”). Now, this is a much broader subject than just coaching, and it goes deep down on consultancy techniques. However, in their book, Rachel and Liz suggest an exercise to help surfacing these disagreements: instead of pulling “yes or no” answers from the team, look for gradients for agreement[2]. Put options on the board that go from endorse to block; help the team to distinguish a wholehearted yes! from a whatever, a I’m not so sure from a no way!. The gradient scale enables the team to see when there is lack of consensus, without reducing the situation to a simple DO or DON’T.

Something fairly obvious, but which might be worth mentioning anyway, is that a team needs reachable but challenging goals. If work is too easy, people get bored and demotivated. If it is looks impossible, people get too frightened to reach for good results. Part of a coach’s role is to help identifying a compelling goal and find manageable chunks of work so that the team continues engaged. Sometimes, the team is motivated by the product they are building[3]; sometimes, by the technology. There are numerous drivers for motivation, and a coach needs to be aware of what the team is looking for to be able to keep everyone on track.

Now, I’ve been talking about what to do as a coach, but it is also important to be self-aware and do not microcoach. No one likes to work with people who always want to know  everything that’s happening, or people who often give advices such as “don’t forget this” and “don’t forget that”. People need space to evolve. The team must have the opportunity to fail, and then learn with the mistakes. If there is always someone in the team who reminds everyone of what should be done, and is always trying to prevent possible failures, the team will end up relying on that person too much. From my own experience, I believe that people learn the most when they actually try their own ideas, analyze the results and then act on it – and that’s where a coach should act: helping people to go after their ideas, and helping them to realize what consequences they are facing and how to improve. Ideally, the coach figure in a team will disappear over time and the team will keep performing their best.

What are your thoughts?

Regards,
-TC


[1] Paulo’s Agile Tips blog ^

[2] The exercise is originally from The Facilitator’s Guide to Participatory Decision-Making (http://www.amazon.com/Facilitators-Guide-Participatory-Decision-Making-Kaner/dp/0865713472/). ^

[3] I’ve seen this often happening in ThoughtWorks, where a lot of good work gets done by people working on Social Impact Projects in their free time. You can find more information here. ^