Of all the abused words in the Agile domain, none seems to be more abused than the simple word “coaching”. There are numerous people out there professing to be “agile coaches”, and while I don’t mean to denigrate what any of these people do, there is a very broad latitude in the types of things that they do. This can further confound our ability to work with organizations as there may be a disconnect between coaches and clients about what exactly they are doing.
Unfortunately, in the absence of a clear understanding, I have seen people begin to expect that the “Agile Coach” is nothing short of a super human being. The can swoop into any project, turn around the results, and simultaneously coach that group into effectively preventing all those problems from ever occurring again. Or they may have an unnecessarily narrow view of the role and try to put an Agile Coach in a box by insisting they only do training, for example. To be fair, when I encounter these missed expectations, they are usually my own fault. I did not do a good enough job of articulating what the role is I, or anyone else, would potentially be playing in that organization as an Agile Coach.
I can’t profess to be the keeper of truth on this topic, but here’s a model I’ve used to help organize my own activities and to make sure I’m articulating clearly what role I see myself playing.
The Agile Coach
Before moving on, let me venture my best attempt at a definition of an Agile Coach, which I am conspicuously labeling with capitalized letters to indicate that it is something very specific to the field of Agile software development and project management, and not to be confused with a professional coach, which we’ll discuss more in a little bit. An Agile Coach is a professional, working internally as a full time employee or externally as a hired consultant, who is working to help realize a profound organizational change to better embrace the values and principles espoused in the Agile Manifesto. Specifically, this is a person who is doing a blend of a number of activities based on the situation to help that organization overcome barriers to change – be they technical, organizational, or skills based. One of the key values of such a person is their ability to play different roles based on the context, and a high level of awareness of these different potential roles can be a critical factor in their effectiveness.
The Pillars of an Agile Coach
When I think about all the things that an Agile Coach must do, I visualize a massive structure that is the change we are trying to realize, something like a building with Roman columns supporting a massive roof. The roof represents the weight of an organizational change, and it is held up by numerous pillars. Each pillar increases the strength of these structure, as well as adding more stability. With more points of contact, the better balanced the roof is. With that visual in mind, I see four primary pillars that make up Agile Coaching: training, mentoring, coaching, and consulting.
Training – Conveying Knowledge and Skills
At this point, I would suspect everyone familiar with Agile Software Development is familiar with the Certified ScrumMaster (CSM) program where people attend a 2-3 day training class to learn the basic mechanics of Scrum and talk about their application at work. This is training in it’s purest form. People are attending a class to learn new skills, usually in an abstract sense. Training is a critical piece in any organizational transformation, as people generally do need to learn new ideas. However, implemented alone, people will fail to adopt these new skills into their regular behaviors and there are numerous studies which show that nearly 90% of everything people learn in a training class is lost shortly thereafter.
Mentoring – Putting New Skills into Practice
Mentoring occurs when people are back in their day to day routine and they work with an Agile Coach to learn and apply new skills in that environment. Mentoring frequently occurs in addition to training and after a training class introduced new concepts. Mentoring is similar to training in that there is a very explicit learner and teacher relationship. The mentor has the answers to the technical challenges at hand and will work with the mentee to put those practices into play. Mentoring may be an Agile Coach working with a Product Owner to help them lay out a story map, introducing the concept, guiding them through it, and assisting them along the way. Mentoring is a very useful technique and is necessary when launching new Agile initiatives to help people put new skills into practice. However it still implies that there is a correct answer or practice, which the instructor is communicating to others.
Coaching – Helping People Find Their Own Answers
If mentoring is helping to teach people the answer, coaching is helping people learn new answers on their own. Coaching as a profession predates Agile Software Development, and there are numerous organizations and techniques such as Co-active Coaching. The key difference here from the two earlier pillars is the nature of the relationship. In this case, the coach is much more of an equal to the person being coached. When coaching, an Agile Coach will serve more as a sounding board and guide through a reflective conversation of observation, reflection, change, and action.
Consulting – Getting Your Hands Dirty
The fourth pillar is the least like the earlier ones, but can be a critical success factor if used correctly. Consulting is when an Agile Coach actually takes on work items for an organization, team, or individual. It may be doing an assessment to better understand what’s going on in the organization and make recommendations. It may be to actually embed with the team and serve as ScrumMaster – or even a developer – for some time. Consulting is powerful for a couple reasons. It can help create early momentum in an organization when there is insufficient energy to get going. It can also establish rapport with a team or organization, as it shows the Agile Coach’s technical capabilities. It also is an excellent opportunity to model good behavior, and we see some coaches move between mentoring and consulting where at times they are teaching, and at other points they are actually doing work to help meet the objectives of that team or project. Consulting is also dangerous for an Agile Coach. As a change agent, they are inherently not quite part of the system as they are trying to help change it to become something else. If they immerse themselves too much they risk losing their perspective in the tactical demands of that work, or that they may come to be seen merely as a “pair of hands” who are useful to keep around but are no longer leading change.
Moving Between Roles
As you can see, it is very hard to realize profound organizational change leaning on only one pillar. In fact, the most successful Agile Coaches I have seen move back and forth between the roles as appropriate. My experience has been that I am most successful when I am aware of the different roles and how they may play out in a given context. For example, when engaging with a new team, they may not be open to a coaching relationship, or they may be overwhelmed and this is just the last thing they want think about. Or conversely, I may be dealing with an executive who is much more experienced than me, and I really am not in a position to approach as a teacher. In this case, a coaching approach may be much more productive. There are probably too many different situations to talk through, but I hope this communicates the key point: that these different roles are situational, all of them are useful at different times and we should be aware of what they are and how we are – or aren’t – using them.