If software development is about wiring code, then coaching is about re-wiring the neurons in each practitioners head and re-wiring their relationships. Yes, coaching is about changing people. You cannot expect a one-size fit all solution, so you need to adapt the recommended practices and approach. This paper discusses how to work with people, how to manage the coaching progress and setting objectives and expectations. This paper also talks about coaching not being just about helping the team learn, but also for you to learn and grow. You have to be agile to coach agile.
1. You Need to Be Agile
Software development is not easy. Finding the right architecture, the right design, even the right system to build is not easy. Couple this with the fact that team members have different backgrounds and potentially different political and religious affiliations, the challenge is even greater. It is under such a context in which coaching takes place. No wonder coaching is not easy. You really need to open your eyes wide. You really need to be resourceful. You need to be agile as a person to coach agile. Not just doing agile, but being agile.
As I always say, “The greatest risk is not knowing the risk. An even greater risk is that you or me might be the source of the risk.” So, it is important for a coach to remind themselves to check their assumptions, to understand what is really good for the team being coached. Where are they in terms of agile practices? Are they understanding correctly? What are their strengths and weaknesses in the application of these practices? Did they make the common mistakes? You can usually find check lists that contain these questions easily on the web.
In addition, a coach needs to check the temperature of all those involved in coaching. The person who brought us into the team would likely be supportive, but the person who is assigned to be the contact person might not be. This contact person is extremely important. Their enthusiasm or the lack thereof has significant impact on the success of coaching. So, do spend time with this person and understand what excites this person. It might be a personal hobby or something. Of course, the team members to be coached are important. Some treat you as God, while others could not be bothered. The key is to get everyone to be honest about their feelings and put this in the open. Hear them out. Let them speak. Do not be too eager to dump a load of agile practices on them without listening to their feedback. Of course, this is not entirely democratic. Many of the good practices take hard work. A coach needs to filter the noise and excuses.
In larger projects or departments, coaches need to work as a team. Of course this provides a reservoir of knowledge to draw from, but it also brings yet another set of challenges – that of speaking in one voice. Different coaches have their different competencies and likings. Coaches tend to emphasize what they think they are knowledgeable in. Moreover, you cannot expect all coaches to know as much as you. Every coach is also learning. They are evolving their understanding, they are evolving the way they communicate their understanding. This might result in confusion amongst the people being coached who get different responses about the same question. So, set expectations. Have a place for coaches to log their opinions – what are non-negotiable positions, what is still open to debate. It is useful to maintain a group blog accessible by the project members.
Dealing with people is unlike measuring temperature. It is not instantaneous. It takes a while. Their understanding changes, their posture changes. So, you always need to be on the lookout. Yet, you do not want to be so political that it wears you out.
2. Continually Clarify Objectives
It is important that everyone knows what they are aiming for and what they are in for. Building consensus is important. Firstly, I would list practices or approaches to be introduced jointly with the team. This list should of course help