The Agile Coach Role Needs a Pivot

First of all, an Agile coach is not just a coach.

Think back on your best teacher. They probably did more than teach. My own best teacher was also a friend and a mentor. In the same way, a great coach does more than coach: they also teach and mentor, and perhaps more.

An organization provides an Agile coach for the purpose of helping a set of teams to improve. It is not life coaching that one seeks by choice. The organization does not expect that the people being coached want to be coached. People often think they know more than they do—that is the Dunning Kruger effect. They don’t know that they need a coach.

The organization wants improvement: they want the teams to become more effective. If you are an Agile coach, and you judge that actual “coaching” will help, then do that. If it appears that some mentoring is required, then do that. If some teaching is required, do that, or bring someone in who can teach the required subject. The goal is to enable the teams to become faster, better, and more capable.

The organization does not expect that the people being coached want to be coached.

Too many Agile coaches focus narrowly, using life coaching as a model, but that is not what organizations are asking for when they bring in an Agile coach. They are asking for their teams to improve.

Second, realize that an Agile coach is a leader. A leader is someone who has influence. An effective Agile coach has a lot of influence: they are therefore a leader, by definition.

Agile Coach as a Leader

One very useful model of leadership is Path-Goal Theory, which proposes four modes of leadership, each appropriate for different situations: directive, achievement-oriented, participative, and supportive. Which of these are appropriate for an Agile coach?

The first mode, directive, sounds like it does not apply to a coach because a coach is not responsible for doing the work of the team. But if one looks at sports coaches, they definitely are directive about some things: “Be here every morning at 6am for drills”. That’s pretty directive. They don’t say, “Come here for practice if you want, when you want” or “If you want to be coached, I will coach you”. They were hired by the team manager to improve the performance of the team. To do that, they need to be directive about some things.

In his book The Servant, James Hunter writes about servant leadership, saying,*

“The leader should never settle for mediocrity or second best – people have a need to be pushed to be the best they can be. It may not be what they want, but the leader should always be more concerned with needs than with wants.”

A coach needs some authority. They need to be able to say to the team, “Trust me: you need to learn this thing and I am going to teach you about it and get you to practice it”.

Authority is dangerous because it is easily misused. Indeed, part of the original impetus for the Agile movement was the preponderance of toxic bosses in IT projects.

Once you give someone authority, they need to have accountability. Otherwise, how do you know that they are using the authority well? Authority is dangerous because it is easily misused. Indeed, part of the original impetus for the Agile movement was the preponderance of toxic bosses in IT projects.

Authority is also a precious commodity: if you dispense authority to lots of people, you start to reduce everyone else’s agency, because suddenly there are too many bosses. Authority needs to be given very sparingly, and if you give it, it must carry accountability.

That’s a big problem with the Agile coach role: as it is defined in most organizations, it carries no accountability: “The teams’ performance has not improved—not the coach’s fault!”

Well, yes it is, to a degree.

The Important—and Agile—Role of Accountability

Coaches need to have shared accountability, along with those who have authority over the actual work. For a group of self-organizing teams that have no leader, authority is distributed equally among all of the people spanning all the teams. Or, if there are designated leadership roles, those are the people who have authority.

Regardless, the point is that if the teams’ performance improves, that is a success for both the teams (their leaders and their members) and the coach. Not the teams or the coach: both. And if there is a problem, the people to talk to are those who are accountable—not to blame, but to discuss what to do—that is literally what accountable means!

Coaches need to have shared accountability.

Accountability also gives you standing. If you have accountability, then you have a job for which results are expected. That gives you a right to demand the time of managers. If a manager perceives that you have no actual stake in the game, they are going to make you their lowest priority. But if you are on the hook for something, they have to make time for you—if they don’t, they are blocking you. But if you have no accountability for anything, they can never be said to be blocking you, because nothing is expected of you.

That’s how most managers think anyway: they are not inclined to spend a lot of time with someone who has no authority or accountability. If you have no accountability, you are not part of the process to them: you are a spectator, not a player. If you have no authority, you cannot commit to anything, and commitments are the currency of people who have leadership roles within an organization.

If you have no authority, you cannot commit to anything, and commitments are the currency of people who have leadership roles within an organization.

Once you have accountability, you suddenly find that you are welcome to talk to people a few levels above you in different parts of the organization, even in closed-door organizations. Those doors open because you have a need to talk to them, based on your accountability.

Some Agile coaches might be off-put by talk of accountability. They might think that an organization that focuses on accountability is a command-and-control one. But that is not true: accountability certainly is part of command-and-control, but command-and-control are not part of accountability. One can have—should have—accountability whether or not one has command-and-control.

Accountability does not mean that people are punished when things don’t go well: accountability means that you are “on point” to lead on something. It means that you are the go-to person for it. It means that you are empowered to make commitments. If you are accountable but things do not go well, people can respond in many ways. Being accountable does not dictate how they respond.

Accountability does not mean that people are punished when things don’t go well. It means that you are empowered to make commitments.

Accountability is an essential ingredient for improving performance. If you learn a subject in school, you are accountable for learning: you take tests, and that is how your accountability manifests. And learning without assessment is very ineffective. Motivators such as mastery and autonomy are not enough if there is no accountability, especially during periods when the work is less fun than usual.

What Should an Agile Coach’s Job Be?

An Agile coach should focus on the performance of the teams that they are coaching. (Some people call that “performance coaching”.) That requires knowing the basics of each area that is relevant. You cannot just “focus on the human side” as a life coach would.

If you focus only on the “human side”, then you are a silo. In an agile organization, everyone who participates in a value stream needs to have a basic working understanding of every part of that value stream. A high value coach helps teams to figure out how to synthesize the different aspects of the value stream. To do that, you have to have a global view—a “systems” view. You don’t have to be able to perform the work, but you need to know enough to have conversations about tradeoffs that span multiple parts of the value stream.

A coach who does not understand technical debt cannot explain it, and therefore cannot persuade a business stakeholder to take an interest in technical debt.

For example, for digital systems a common tradeoff is between building more features and reducing technical debt. If you have a business stakeholder who has no understanding of what technical debt is, they will be resistant to hearing about it. But if they have seen it firsthand, and have tangible memories of it, they will be more interested, and they will be able to have conversations about whether to invest more in new features or to fix some of the technical debt. A coach who does not understand technical debt cannot explain it, and therefore cannot persuade a business stakeholder to take an interest in technical debt.

Again, you don’t have to know every area in depth: but you have to have seen it firsthand. When I explain technical debt to business people, I use an example they can relate to: spreadsheets. I say, “Imagine you have a 100 sheet spreadsheet, with lots of interlinking between sheets, and over time it has become kind of a mess. Now imagine that someone wants you to add a new set of formulas in some new sheets that reference other sheets. Do you feel confident, or do you think it is time to clean up the other sheets?”

Once they hear that analogy, they get it. They have seen it. People need tangible memories about ideas. Only then can they use those ideas. And I am only able to think of and explain the spreadsheet analogy because I have firsthand experience with spreadsheets and also with software technical debt.

What an Agile Coach Should Teach

Another coach and I were once asked to define the content of an “Agile basics” course. I came up with a draft, and so did he, and we then compared. His draft was all about Scrum practices. My draft did not even mention Scrum.

Agility does not result from following process steps.

The Agile community teaches the wrong things. Organizational agility results from (1) agility-promoting behaviors such collaborating effectively and voicing your ideas, (2) knowledge of agility-promoting patterns such as Lean and DevOps patterns, and (3) having a culture that is supportive of (1).

Agility does not result from following process steps. Agile 2 ties together agility-promoting behaviors (number 1) and patterns (number 2) into a cohesive whole. These encompass leadership styles, effective (and neurodiverse) collaboration approaches, and Lean and DevOps patterns such as feedback loops and systems thinking. These are first and foremost what an Agile coach should be teaching and coaching their teams.

A coach cannot know everything, but a coach should have the big picture, and know how everything fits together. A coach can bring in subject matter experts, to help train and coach a team in DevOps practices, leadership, machine learning, low-code, and other topics that are important in the situation; but the coach should have a solid understanding of the way these things work together, and be able to follow or lead a conversation about how teams should utilize these ideas.

Contrary to Scrum’s very un-Agile advice that a Scrum Master should be “Leading, training, and coaching the organization in its Scrum adoption”—as if adhering to Scrum is the goal—an Agile coach should be helping team members to be effective. The effectiveness of a group depends on the quality of leadership, the quality of collaboration, and the quality of each individual’s work. Improving those things, rather than honing people’s adherence to Scrum events, is what the focus of an Agile coach should be.

* Page 66, “The Servant: A Simple Story About the True Essence Of Leadership”, by James Hunter, ? 1998, published by Crown Business.