Agile Coaches, Agile Guides and Other Family Members

When Lewis and Clark set out to explore the Louisiana purchase in 1803 they didn't have a map: making a map was part of their mission. Without a map a plan was impossible, but how could you plan a journey into the unknown?

That does not mean they didn't prepare. Funding was secured from congress. Lewis invited Clark to co-lead the expedition. A boat was built for the first part of the journey - so they knew they were starting by water. And they prepared their minds: Lewis studied medicine and navigation in preparation.

I'm no authority on the expedition, and for all I know they may well have created a plan however I can't imagine President Jefferson complaining they hadn't reached the Pacific on schedule. Any plan would have shown as many unknowns as it showed knowns, the expedition existed to explore the unknowns.

But they did have a guide, several in fact. These guides knew some - but not all - of the territory they were crossing and could help them find routes. Guides could also help with interpreting what they found and speaking to indigenous tribes.

When we develop software we are entering unknown territory too: we may think we have a plan and we may think we know what we are building but how many initiatives stay the course? Our plans contain many unknowns. Reality seldom goes to plan and efforts pivot as a better understanding of customers wants emerge.

Preparing for agile

For teams adopting agile approaches there are two challenges. The first is the thing they are building, the challenge for which they exist.

The second is agile itself. In truth, since agile is a journey into learning and continuous improvement, agile is never finished. What starts as "adopting agile" becomes sustaining and improving working practices and processes.

Preparing for both challenges makes sense. Secure some funding, recruit the right leaders, consider the first stages and prepare your mind - learn from others: training, books and blogs. But planning?

When one is journeying into the unknown, plans have limited value simply because one doesn't know. The bigger the plan, and the more superficially complete the plan, the greater the challenges when innovating.

But why spend time on planning when you could get yourself a guide? Someone who has been over the same, or similar, territory before and can help you navigate the obstacles?

In truth many teams do secure the services of a guide. These people go by the name Agile Coach. However, even as the Agile Coach has become an accepted role in development teams a number of problems have built up with the role.

Conflicts in coaching

Question: should an Agile Coach present solutions?

When in the role as an Agile Coach I have spent days agonising when the organization and team expect me, their Agile Coach, to fix things. But I know, as a coach, I should help them find their own solution. Is it right for me to hold back my knowledge? Am I best serving my client by not doing what they expect me to do?

Question: When a team are content with their way of working, should an Agile Coach initiate change?

The biggest conflict in agile coaching is between the way organisations often view the coach role and the way coaches themselves see their role. Companies frequently see the coach as a change bringer, but coaches usually see their role as an enabler. In coaching terms this the difference between directive and non-directive coaching.

Many agile coaches take their lead from the earlier field of business coaching. Authors like John Whitmore and Myles Downey have long advocated a non-directive style of coaching where the coach helps the individuals resolve their own problems. Whitmore writes:

"Coaching is a management behaviour that lies at the opposite end of the spectrum to command and control. ... A skillful coach rarely provides or prescribes solutions." Coaching for Performance, Whitmore, 1992

In their work coaches often utilize the Socratic method to help coachees unlock problems and decide actions. Unfortunately, asking lots of questions, and not providing solutions, is usually not what companies expect from their coaches.

Organizations frequently see agile coaches as agile experts and agile leaders. Such coaches can facilitate meetings, teach agile and organize work in an agile fashion. Organizations expect coaches to deliver too, so coaches may be part of a coaching team that has its own agenda and success criteria.

Such organizations frequently expect coaches to deliver results and follow a company plan. But that does not mean individuals in teams are open to being coached. It is hard to coach someone who is not motivated to be coached. A true non-directive coach respects the individual's preferences and will follow the individual's agenda not the organization's.

In the extreme, organizations mistake coaches for managers. Not long ago a Swiss developer told me: "I got an email from my coach today expressing concern about my outstanding vacation balance, and that I had better have plans to use it all."

Some organizations are expecting, and even looking for, a more directive style of coaching. In directive coaching the coach is a kind of expert - think of the football coach shouting instructions at players. Organizations frequently expect agile coaches to know the answers to problems rather than lead individuals on a journey of discovery.

While both coaching styles have their merit, the self-organizing philosophy of agile naturally tends towards the non-directive approach. Indeed, a few agile coaches - often the most experienced - have qualified as professional coaches by pursuing multi-year degrees and diplomas.

This conflict is problematic in itself for the coach, for the organization and especially for the team members. Teams can find the style of coaching they experience is at odds with their expectations. The conflict appears in the recruitment of coaches too. What experience should an Agile Coach have? How much knowledge of agile and software development should they have?

Non-directive coaches do not necessarily require experience in software development or agile. Instead, they need to be skilled in listening, in Socratic questioning, the non-directive style and experienced at helping others find their own solutions.

Conversely, directive coaches actively need to have knowledge and experience of agile - and the more the better! Unfortunately, it is common to hear stories of coaches who lack experience in even basic agile ideas.

A few years ago a senior coach at a global bank told me how the bank had hired dozens of agile coaches. But in doing so the quality of coaches slipped and some of them "don't know how to play planning poker." Regardless of what you think about planning poker, and even estimation in general, this lack of knowledge bodes ill for the quality of the coaching.

Then there is the question of software development experience. It is not uncommon today to find coaches who have never coded or been part of a development team. For a pure (non-directive) coach that is not an issue - indeed, an open mind can be a positive advantage. Their skill set is helping others find their own solutions. But when the coach is expected to give direct advice and guidance, having such experience is essential.

Naming the conflict

Failure to resolve these conflicts means I've never felt completely happy with the term "Agile Coach." One approach is simply to name the problem and ask the client hiring a coach "what do you expect?"

Hence my earlier questions and agonies. Am I there to use my experience and skills to resolve problems? To direct people towards a brand of agile? Or should I help unlock the team’s own solution?

There are no easy answers to this, no one model that works everywhere. John Clapham has worked as an Agile Coach for over 10 years and says that these are common quandaries for all professional coaches. He notes that different coaching styles have different stances concerning the degree to which the coach is "in" the conversation, if and how they offer opinions and knowledge.

John invites conversation about role clarity and client expectation from the start. He avoids the term "Agile Coach" and describes himself as a "Professional Coach and Agile Consultant". He says: Once fairly narrow and emphasizing the agile aspect, the term "Agile Coach" now encompasses a broad range of approaches and methods.

This is not unlike people applying to join an orchestra and simply describing themselves as musicians. Alone the title is not sufficient to know where someone will fit or the role they will play. The challenges are increased by the many types of coach and the degree of coaching competence displayed.

Rename the role

My own solution has been to avoid the title "Agile Coach." But that leaves the problem of what to use instead?

"Agile Consultant" more accurately describes the teaching and advice I give but nobody, including myself, seems to like the term "consultant."

At its best the "consultant" title simply describes a worker who is not employed permanently by the organization. But at other times consultants are seen as enforcers of predetermined processes that allow little room for workers input.

Ultimately the title "consultant" is simply too broad to really describe anything and carries too much negative baggage.

Over time I came to see that I didn't so much help teams unlock their own solutions as help them find a way through the issues they faced. As such this was more of a guiding role.

I was taken with "Agile Pilot" but that makes the role sound too much like an experiment. Besides, while those of us from a seafaring background know pilots guide ships through difficult passages everyone else see pilots at the controls of airplanes commanding passengers to fasten their seat belts.

"Agile Navigator" might avoid the pilot ambiguity but one well-known consultancy uses that title in their own version of agile for a project manager like figure.

Gradually the guiding metaphor grew on me and I started to call myself an "Agile Guide". Then I did some research, and to my surprise others use this title, when I investigated some more I found they define an Agile Guide in much the same way I do.

As an Agile Guide I

As an Agile Guide I see my job as helping guide individuals, teams and enterprises to greater agility while delivering useful products. I don't have all the answers but I have some, more importantly I seen what others have done and what is possible.

Guiding breaks down in three main ways. First off is simply teaching new ideas, approaches and skills to people. Sometimes that is in a classroom or conference setting. Sometimes in one-on-one conversations and sometimes through my writing, blogs, books and articles plus podcasts and videos.

Second is direct specific advice. Of course teaching - especially in the classroom - is itself advice but advice giving continues beyond the classroom setting into the delivery process. Classrooms can be sterile environments, everything works in the classroom. So often people leave the room and say "We'll try that on the next project in six months" or "It all sounds good but it won't work here."

Especially when a team is new to agile every decision has a potential agile aspect. Often teams - and particularly leaders - do not see an agile alternative to a decision. Sometimes looking at a question through the lens of agile offers a different answer. That is especially true when priorities are in play.

So part of the Agile Guide role is to say "You know, there is a different way of approaching this". After explaining some agile technique or approach the team can take different decisions.

That advice may be presented in conversation, in reports or in presentations. Other times it means asking questions and challenging assumptions, existing ways of working and even people. Sometimes it means sitting down with decision makers and saying: "You want to be agile, you've employed me to help you, and the next thing you need to do is..."

The final part of my work is what I consider "true coaching". By which I mean non-directive coaching where the coach helps the coaches find their own solution. Non-directive coaching is a skill in my toolbox but I'm not an expert non-directive coach.

Leadership

Agile Guides are leaders but they are not the only leaders - they are leaders but not the leader. They have been over this territory before so it makes sense for them to lead. That is an important way in which a guide differs from a coach. A coach - especially a non-directive coach - encounters conflicts when they put their own ideas to the fore.

Guides exhibit leadership through the teaching and advice giving but there are times when the guide themselves stands in harms way. Those outside the team may see the guide as the leader rather than one of several leaders.

Distributing leadership within a team makes sense because it allows specialists to lead where they have passions. But distributed leadership also means accountability and responsibility are vague, there is no longer "a single wringable neck." Consequently those outside the team don't know who to talk to or complain to when things go wrong.

While guides give advice and lead that doesn't mean they have final authority. They may acquire authority through respect but the guide is a hired hand, team members, and other leaders are free to ignore the guide and their advice.

Coaching family

Consider again the analogy with musicians. For anything but the most general conversation one needs to go further than saying "I'm a musician". One needs to say "I'm a violinist", "I'm a heavy rock drummer" or "jazz saxophonist."

There has long been a variety of agile coaching roles and it is time they were called out. Technical Agile Coaches different from process coaches. Technical coach roles further break down between those who focus on TDD, DevOps and Test automation coaches.

So perhaps rather than seeing a single Agile Coach role one needs to think about a family of roles which includes guides, technical coaches and Scrum Masters. Naturally, some of these roles overlap and some coaches have more than one string to their bow but we need to recognise that.

Calling out the Agile Guide as a type of coach role in its own right solves a number of problems. The conflict between how role holders view the role and the organizations expectations are massively reduced. Having an Agile Guide role allows agile coaches to focus on the essence of the coach role: helping individuals become better versions of themselves without being directive. And in separating the two roles it makes clear the kind of experience required for each role.

Finally, since adopting the Agile Guide moniker I've been happier in myself. I understand what I do and where I define my role. The main problem I face is that the consulting market has decided the role name is "Agile Coach". The upside is I then get to tell people why I call myself a guide, not a coach.

What about Scrum Masters?

Renaming roles such would solve another conundrum: what is a Scrum Master?

In some parts of the industry Scrum Master has come to be seen as a junior Agile Coach. But Scrum Master does not obviously seem to prepare people for a non-directive coaching role.

Look at some of the things the Scrum Guide says about the role: "accountable for establishing Scrum as defined in the Scrum Guide", "Scrum Masters are true leaders", "Causing the removal of impediments to the Scrum Team’s progress" and "Ensuring that all Scrum events take place and are positive." That all sounds pretty directive.

The same guide also says "Coaching the team members in self-management and cross-functionality" so again the Scrum Master role potentially includes elements of directive and non-directive work.

Given this understanding it is entirely possible to see how being a Scrum Master prepares one to be an Agile Guide more than a pure coach.

Acknowledgment

Thanks to John Clapham for comments on an earlier draft of this article, and thanks to both John and Woody Zuill for their insights into the agile coach and agile guide roles.

References

• Whitmore, Coaching for Performance, 1992
• Deny, Effective Coaching, 2003

About the Author

Allan Kelly guides software professionals enjoy more fulfilling and satisfying work by improving the way work is organised and requests are made. Happier people and better ways of working make for more effective companies, greater value and competitive advantage. His wide experience of the challenges faced in software development underpins his advice, coaching, training and writing. Allan's latest book is "Succeeding with OKRs in Agile".