When Does Coaching End and Doing Start?
When Does Coaching End and Doing Start?
When teams implement an Agile system, the role of the Agile coach can cause some confusion. Coaches are meant to facilitate, not do.
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
“Coaching is unlocking people’s potential to maximize their own performance. It is helping them to learn rather than teaching them.” - John Whitmore
Coaching is an interesting and confusing notion. In my current role as an Agile Coach, we must be explicitly invited by a team or an individual to coach. Usually, this is driven by an awareness of a specific problem or a general desire to improve in some area. The goal of the coaching is to enable an individual or team to solve the problem or to provide structure and support to enable the learning. The goal is not for the coach to solve the problem.
This can cause some confusion. A team has asked for help with a problem and as the Agile Coach, you are not going to help them solve it? In fact, you may actually let them fail and watch them flounder – but how is that helping?
This essentially gets wrapped up in the whole “Give a man a fish you feed him for a day, teach a man to fish and you feed him for a lifetime” thought process. A coach wants to equip the team or individual with the skills to solve – not just this problem but the next problem and the one after that. A coach may very well know an answer to the problem described, but the agenda of a coach is to grow the team into being able to solve the problem on their own, or at the very least to understand why a particular solution may be appropriate. This can lead to confusion and frustration especially if the problem is causing pain or costing money. The team often wants the problem solved far more than they want to learn at that time.
A coach may ask questions that guide thought processes or sow seeds of ideas, and they may point out examples of behaviors that may be dysfunctional and warrant further thought. All of this is intended to focus attention where it can have the most impact, but all without explicitly solving the problem. But when the team doesn’t understand this relationship, it may appear that the coach is not helping and can build tension. After all, the coach may appear to only identify problems but doesn’t offer any solutions. This a common failing of coaches. There is a certain irony that one of the most common coaching guidances to give is to teach the understanding of “the why” of a situation, but sometimes coaches miss explaining this vital information when it relates to their mentoring. But when you coach multiple teams it is very easy to assume that everyone understands the coaching relationship and this can lead to confusion and frustration.
A very useful example is a situation where two people on a team are having interpersonal issues. Let’s take, for example, Wendy. She continually leaves a mess at a pairing workstation and this drives her colleague Paul crazy. He gets frustrated and seeks out a coach and asks the coach to help. The coach will very likely ask if Paul has discussed this with Wendy and if not why not. Paul may ask the coach to speak on his behalf or to mediate, but again, the coach may suggest that Paul act alone to remediate the situation. The coach may offer guidance on how to have difficult conversations (and, in fact, the coach could offer a great book on this subject: “Crucial Conversations”) but it is not the Coaches’ role to be the mediator or to engage in conflict resolution. If the matter is more serious they may refer the issue to HR just as anyone else might, but it is not the Coaches role to solve the problem or to get involved, merely to equip the person with the tools necessary to solve their own problem.
Levels of Coaching
If you consider coaching on a one-to-one level it may be easier to see how the different levels of coaching are applied, and when or why different techniques are applied.
Let’s take the writing of the first draft of a user story as an example.
- At one end of the spectrum, the coach could teach or talk about general story writing techniques and practices and give examples. (Teaching) abstract ideas – blogging, courses, lectures, presentations, etc.
- Or it might be useful for the person being coached to work through a generic example with the aid of a coach (Training). Workshops or interactive activities such as games.
- Or it might be useful for the person being coached to work through a real example with the coach available to ask questions or the coach asking questions and offering encouraging ideas (Coaching/Consulting/Advice).
- In some cases, the coach may sit with the person being coached as a partner, sharing thoughts and ideas in a balanced way, thus sharing the work (player coaching/mentoring).
- At the other end of the spectrum, it may be that the coach actively participates in a pairing situation and shows the person being coached what is being done and explaining why. At this point, the line between coaching and doing is a line in the sand and depending on the engagement level of the person being coached the level of learning and improvement may be negligible.
- And finally, the coach does the work on behalf of the team/individual even though the team could do it for themselves. At this point, there is no coaching value at all.
Of these five levels, most Agile Coaches operate at level 2 and especially level 3, occasionally some in levels 1 and 4, but 5 is unusual. We find that it’s best to say that we shouldn’t ‘do’ and if we stray we should be aware that we are no longer coaching. In contrast, a Scrum Master spends more time at 3 and 4 and often at 5 or even 6 – resolving impediments, producing metrics, etc. But the overlap between the roles is subtle and there is no hard line. It is more a question of the intended outcome, rather than how it is achieved.
Of course the ideal and the reality can be quite different. I have been giving a product owner coaching recently and this is a double-edged sword, as the product owner aspect of software delivery is one of my favorites and I get enthusiastic. Therefore, I have been helping write story maps, write stories, and identify personas, but every once in a while, I’ll start doing, throwing out my ideas, making corrections without discussion, and taking over at the keyboard! Thankfully, usually one of us will spot it quickly and non-verbal cues will put me back in my coaching box.
My point is that not understanding the goal of the coaching leads to all sorts of problems, as the teams facing a particular problem may feel they are not getting the assistance they need. It may be difficult to measure whether a coach is effective when they go out of their way not to ‘do’ something. The role is both very broad and very misunderstood.
But when the role is understood and when those being coached understand the relationship and the value of it, the situation changes drastically. It is a rewarding role and the relationships can be fun and fruitful. When you accept that you are expected to solve your own problems (with guidance) it can be very empowering. A coach becomes someone that can help YOU expand YOUR understanding and ability, but the credit belongs to you, not to the coach. They just point the way – you have to do the work.
Published at DZone with permission of John Yorke . See the original article here.
Opinions expressed by DZone contributors are their own.