\r\n\r\nJust this week I stumbled upon a short article written by Barry Overeem. There he refers to a model called “the 9 coaching roles”, which is part of a course by Esther Derby and Don Gray. Awesome, because that model immediately inspired me and helped me recognize what I am doing as an agile coach myself. I already used the model to explain a team what I am doing as a coach which made them quickly understand both my role as a coach and…their own challenges!\r\n\r\nBelow, I elaborate on the model and explain how I am using it myself while acting as an agile coach and challenging myself to become better at that job.\r\n\r\n9-vlaks coach model\r\n\r\nFirst of all, it looks quite obvious to me that we should have a very limited role in the far right column. That column, consisting of “partner”, “modeller” and “hands-on expert”, displays roles in which we are taking responsibility for a team’s results by doing their work. I believe a coach has no business being a hands-on person doing the team’s work. Especially the hands-on expert role in the lower-right corner is out of the question for us coaches. If a team really needs help to do that kind of work, they should hire a competent team member. Only if we consider ourselves a member of the team we might find some value being a modeller or a partner.\r\n\r\nFor example, a Scrum Master or Projct Manager could help a team by taking care of impediments for a while so the rest of the team can focus on team building, getting a development process in place and then learning to be productive. As time and skills advance, that Scrum Master or Project Manager involves her team mates in doing the impediment job together with her, evolving to a partner. Personally I enjoy doing that kind of work for a while, but I still prefer somebody else playing that part of the game. Mostly because there’s often more than one team busy changing their game and I see it as my job to help create coaching competency from within the teams.\r\n\r\nThen the middle column is all about leaving the real work to the team while providing the means to them to do a great job. The technical advisor will advise the team what to do next, being an expert. The teacher provides principles, methods, practices and tools that were previously unknown or not understood by the team and teaches them to use them properly. Both in a class room (or laboratory) setting and on the job. Finally, as a coach we don’t really teach. Instead we challenge a team member or the full team to find proper solutions. We take these roles when a team shows lack of skills and needs more than a bit of help to successfully implement their agile processes. The more the team knows and the more competent they become, the more we can move up from being an advisor and trainer to being a coach.\r\n\r\nFinally the left column is us being completely hands-off. We just observe and let the team decide what to do with our observations. We facilitate sessions, games, or whatever to have them decide on something, adopt something or build a team. Finally, as a counsellor we are just available for them: we act as a mirror, denying any responsibility for what’s theirs. We mainly use questions to help the people in the team become self-aware and use their potential. We sit back, relax and let a great person solve their own problems because we believe in their unlimited potential.\r\n\r\nNow the real trick is how to apply all these different roles as an “agile coach”, because that’s often how we brand ourselves. Only when consciously choosing the role we play at a certain moment, considering the context of that moment, we can be really effective.\r\n\r\nFor example, counselling is almost impossible if people are both untrained and uncomfortable. And observing quickly turns into training if people don’t seem to understand what you observe, making us explain everything. On the other side, acting as an advisor will only deprive a great team of their own responsibilities, as is unnecessary training, modelling and even coaching. And if we keep sending a team summaries and reminders after we facilitated THEIR events, well…I guess you get the point.\r\n\r\nI believe we first have to assess what kind of interventions a team needs when we start working with them. Are they eager to start, craving to learn and acting pro-actively already? Then perhaps we should start being a counsellor, facilitator or observer and see how the team responds to that. We can choose to hold back and let the team show what they can do themselves. Wouldn’t it be great if they turn out to be expert learners and superhuman problem solvers already? Let’s refrain from training them or even coaching them. Let them come to us for questions. Let’s start with believing in their potential. People often start acting in a way which is completely in line with how we treat them, remember? Let’s not fuck up their potential by stepping in too soon.\r\n\r\nOnly if we see the team just pretending to be great while ignores responsibilities (in both directions), when the team shows lack of understanding of essential concepts or when people start asking us to clarify certain concepts, THEN we start advising, training and coaching and thus moving to the right in the model. If the situation is really “bad”, like when the team suffers from major technical debt, serious lack of skill or undeniably suffocating dependencies, only then we move further to the right in the model. We step in ourselves or have other people make sure the basic conditions for this team to have any chance to change and improve are filled in. Which would look a lot like managing, dont you think? :-)\r\n\r\nAnd that’s just starting! But we want the team to become self-organizing and self-disciplined, don’t we? Now let’s assume the team gets to a point where they can actually focus on growth instead of just losing energy while dealing with the rat race.\r\n\r\nPersonally, I’d like to witness when we start moving from right to left on the model. When the team is able to take responsibility for results because the most disturbing impediments have been cancelled out, when the team is multi-skilled enough and people understand and truly take their responsbilities based on an internal drive. Then training on more advanced concepts starts becoming way more effective because the resistance is a lot less and people feel they have space to move and actually get real results.\r\n\r\nFor me there’s an awesome moment when the team starts organizing their own teaching, diminishing the need for me to act as a trainer. They start reading and sharing relevant articles. They start organizing sharing and learning sessions (without often even thinking of inviting me, the coach). It feels awesome when I deliberately stay away for a while and they do a really great retrospective themselves, inventing a great new way to do it at the same time.\r\n\r\nHere’s the catch: we are effective as coaches when we help a team drive us into a counselling-only position. When they drive us to the upper-left corner of the model, they’ll eventually drive us out completely. And then we can actually step out without worries because now THEY act completely autonomous in the model. They have learned to, either consciously or unconsciously, choose their own interventions in any of the nine roles.\r\n\r\nThis model has helped me gain a better understanding of what I am doing as an agile coach. It also made me realize why sometimes I am not effective as a coach: I didn’t always understand why a team responded in the way it did. Now I have a much better understanding of that. The model certainly helps me choose my interventions more consciously. It feels like I can unlock much more of my own potential now.\r\n\r\nI hope it will help you too.\r\n\r\n