ACI's Agile Coaching Competency Framework

The Coach Who Never Actually Coached

About a year into my first serious coaching engagement, a colleague asked me how it was going. I told her it was going well — the team was making good progress, the product owner had really grown into the role, the engineering lead was starting to think more systemically about technical debt.

“That’s great,” she said. “What coaching questions have you been asking?”

I started to answer and stopped. I ran back through the past three months in my head. Retrospectives. Sprint reviews. One-on-ones with the team lead. Planning sessions. I’d been busy. I’d been helpful. I had strong opinions about their sprint goal format and I’d shared them. I’d taught them the INVEST criteria for user stories. I’d shared war stories about how a previous team handled the same dependency problem. I’d given the engineering lead a book.

What I had not done — not once, with any real intention — was ask a powerful question and then shut up.

I had been teaching. I had been mentoring. I had been advising, consulting, cheerleading, and occasionally lecturing. All of it well-intentioned, some of it genuinely useful. None of it coaching.

This is an extraordinarily common realization for people in agile coach roles, and it’s both uncomfortable and clarifying in equal measure. The Agile Coaching Competency Framework, developed by Lyssa Adkins and Michael Spayd at the Agile Coaching Institute, exists precisely to make this kind of gap visible. Not to judge you for it — the framework has no interest in judgment — but to give you a map of the territory and a mirror to check where you actually are versus where you think you are.

Adkins’ book Coaching Agile Teams (Addison-Wesley, 2010) remains the essential reference, and if you work with agile teams in any coaching capacity and you haven’t read it, go read it before you finish this page. It’s not a methodology book. It’s a practitioner’s book written by someone who came to agile coaching through an ICF-certified coaching lens and brought that precision to a field that badly needed it. The framework in the book — later refined into the ACI’s formal competency map — is both a professional development roadmap and, if you’re honest with it, a self-assessment that will show you things you’d rather not see.

The Map of the Territory

Eight Competency Domains

The framework identifies eight distinct competency areas that an agile coach needs to develop. Note the word distinct. Not overlapping, not interchangeable — each one describes a different kind of expertise and a different relationship to the people you’re working with.

The ACI framework arranges these competencies visually as a wheel, with Agile-Lean Practitioner at the center — the foundation all other competencies rest on — and the other seven surrounding it. The visual matters: no stance is independent of the practitioner’s core agile knowledge, and the stances around the edge interact with each other constantly.

The Stance Question: When to Coach, When to Teach, When to Mentor

Here is the part of the framework that changes how you work most immediately.

Most people who use the word “agile coach” conflate it with four or five very different things. Teaching someone how retrospectives work. Mentoring a new Scrum Master through their first sprint. Facilitating a team’s quarterly planning. Helping a technical lead think through a career decision by asking questions until they find their own answer. These are all legitimate, valuable activities. They are not the same activity, and confusing them costs you and the people you’re serving.

The coaching stance — in the ICF sense that Adkins brings to the framework — is the most misunderstood of the lot. Coaching, properly practiced, means the coach believes that the person being coached already has the capacity to find their own answers. The coach’s job is not to provide better answers; it is to ask questions that help the coachee access their own thinking, challenge their own assumptions, and arrive at insights that are genuinely theirs. The coach doesn’t own the insight. The coach created the conditions for it.

That is a very different relationship from teaching (where you have knowledge the other person needs) or mentoring (where you have experience the other person can learn from) or facilitating (where you are responsible for the group’s process). All four stances have their place. The skill — the actual professional skill — is reading the situation and moving between them with intention.

Adkins describes this as knowing which “stance” to occupy at any given moment. A team that is brand new to agile probably needs teaching and mentoring more than coaching — they don’t yet have enough context to generate useful answers from powerful questions. A team that has been practicing agile for two years and is stuck in a pattern they can’t name probably needs coaching more than teaching — they have all the information, they just can’t see what they’re doing. A team in a heated conflict about architecture needs facilitation — someone who can hold the space and the process without taking sides.

The mistake most agile coaches make is defaulting to the same stance regardless of the situation. Usually that default stance is teaching or advising, because those stances feel useful and concrete and they avoid the discomfort of sitting with someone in silence while they work something out.

The framework makes your default visible. That visibility is the point.

The Self-Assessment Function: What the Mirror Shows

Adkins and Spayd designed the framework with a self-assessment dimension that I have watched professionals use with something between enlightenment and existential discomfort — sometimes in the same conversation.

Here is what the self-assessment typically shows.

Early-career agile coaches tend to cluster their time and attention in two competency domains: Agile-Lean Practitioner and Teaching/Mentoring. They know the frameworks, they’re excited about them, and they share that knowledge generously. This is not bad. It’s actually how most agile coaches start, because most agile coaches were practitioners first — engineers, project managers, product people — who developed strong agile knowledge and were then pointed at teams to help. Teaching and mentoring is what they have to offer, and they offer it well.

The gap shows up when you look at Professional Coaching. Most people who hold the title “agile coach” and have fewer than five years of experience have done very little ICF-style coaching. They ask leading questions. They ask diagnostic questions. They occasionally ask rhetorical questions. What they rarely do is ask genuinely open questions and then trust the coachee to find an answer without being nudged toward the right one.

The gap also shows up in Transformation Mastery. It is possible to be very good at helping a team — helping ten teams, actually — while having a relatively thin understanding of how organizational systems shift. This becomes a limitation precisely when the work stops being about teams and starts being about the conditions teams exist in.

Technical Mastery is a separate conversation. Many agile coaches come from non-technical backgrounds. Some come from technical backgrounds but let their skills atrophy. The framework doesn’t demand that every agile coach be able to write production code. But it does name Technical Mastery as a competency domain, which means it names the gap honestly for coaches who can’t meaningfully engage with their engineering team’s work. That clarity has practical consequences: it might mean partnering with a technical coach, deepening your own technical knowledge, or being honest with clients about the limits of what you can see.

The framework doesn’t tell you what to do about the gaps it reveals. That’s intentional. It’s a map, not a prescription. But a map you actually look at honestly is more useful than a prescription you accept without checking whether the diagnosis was right.

What This Changes About Your Coaching

Using It as a Self-Assessment (The Honest Kind)

There is a version of using this framework for self-assessment that is basically a parlor trick — you look at the eight domains, think “yes, I do all of these at least sometimes,” and feel professionally validated. That version takes about four minutes and produces nothing useful.

The version that actually changes something takes longer and involves sitting with some uncomfortable specificity.

Pull out a calendar or a journal from your most recent active coaching engagement. Account for a typical week. How did you actually spend your time? Not how you would categorize your role, but what were the actual verbs — teaching, advising, story-telling, meeting-facilitating, question-asking-and-listening? Then map those activities to the competency domains and look at the distribution.

Most coaches who do this honestly discover their actual distribution is narrower than their self-image. They are a teaching and mentoring machine with some facilitation sprinkled in, and almost no time in the pure coaching stance. That’s not a failure — it might be completely appropriate given the team’s maturity. The question is whether it’s a deliberate choice or a default they haven’t examined.

The second question is harder: when was the last time you asked a question you genuinely did not know the answer to? Not a Socratic question pointing the coachee toward your preferred answer. A genuinely open question, where any answer the person gave would have been equally valid and useful, and your job was to reflect it back and help them think further into it.

If you have to think for a while before you can name an example, that is your self-assessment result.

Using It to Name What Kind of Support a Client Actually Needs

The framework is not just a mirror for coaches — it’s a vocabulary that can help clients articulate what kind of support they’re looking for. And those are often not the same thing.

A common scenario: an engineering manager approaches you with something that presents as a technical problem — their team’s cycle time is too long, their deployment quality is inconsistent. They want recommendations. They want a framework. They want to know what other teams do. That is a request for teaching and consulting.

But if you pull on the thread a little — “help me understand what you’ve already tried” — you often discover that the engineering manager already knows the answers. They’ve read the books, they understand the theory, they’ve tried two or three approaches. What they actually need is coaching: a thinking partner who asks “what’s stopping you from acting on what you already know?” rather than someone who gives them answer number four.

Naming the difference explicitly with the client — “it sounds like what would be most useful right now is less about information and more about thinking through what’s in the way — would that be right?” — accomplishes two things. It clarifies what will actually help. And it starts building the client’s own understanding of what different kinds of support look like, which is a capability worth developing in its own right.

Using It for Organizational Coaching Capability Development

One of the most interesting applications of the framework is at the team and organizational level — not as a tool for individual agile coaches but as a lens for asking, “What coaching capability does this organization need to develop over time, and are we building it or maintaining a dependency?”

The dependency question matters. If a team has had an agile coach for eighteen months and still cannot run their own retrospectives without facilitation support, something has gone wrong. The coach has, probably with the best intentions, occupied the facilitation stance consistently without doing the work of building the team’s own capacity to facilitate. The team hasn’t learned to facilitate — they’ve learned to have their coach facilitate for them.

The same pattern appears across all the stances. A team that has been taught agile frameworks for a year and cannot teach them to new team members. A team whose product owner has been mentored in backlog management but has no idea how to mentor the next product owner. An organization that has imported transformation expertise without developing any internal change capability.

The framework, used at the organizational level, asks: which of these capabilities are we actively developing in the system, and which are we supplying from outside in ways that keep the system dependent? The goal of good coaching is always, ultimately, to be unnecessary.

What It Looks Like in the Room

Priya had been an agile coach for four years. She was good — genuinely good, with a sharp facilitation instinct and real technical credibility from her former life as a developer. The clients liked her. The teams she worked with usually improved. She had a waiting list.

She was also, by her own description, stuck. Not in her career exactly — the work kept coming. More like stuck in a rut she couldn’t quite name. Every engagement felt like variations on the same engagement. She knew what was going to happen before it happened. She knew what the teams were going to say, what problems they were going to surface, what interventions would help. She’d been right every time for about two years. It was starting to feel less like competence and more like a script.

She brought this to a coaching conversation with her own coach, a guy named Roshan who had been coaching coaches for about a decade. They had a standing monthly conversation that Priya found valuable but not quite valuable enough — she was always thinking about how to make it more useful, which she recognized as a slightly ironic problem.

Roshan asked her to walk him through a specific recent engagement. Not the whole thing — just one moment from the last week where she’d felt that familiar rut feeling. She described a one-on-one with a senior engineer named Tomás who had been struggling with the team’s technical direction. He’d come to Priya with a specific question: “Do you think we should move to a microservices architecture?”

“What did you say?” Roshan asked.

Priya described the conversation. She’d asked a few questions to understand the context — the team size, the current architecture, the pain points. She’d shared her experience with teams that had made similar migrations. She’d outlined the common failure modes. She’d described the conditions under which microservices tended to succeed versus backfire. She’d left Tomás with a framework for thinking it through.

“And what do you think he actually needed?” Roshan asked.

Priya started to answer and then stopped. She sat with it for a moment. “He already knew the answers,” she said slowly. “He’s been an engineer for twelve years. He knows the tradeoffs. He wasn’t actually asking me what to do.”

“What was he asking?”

She thought. “He was asking… whether it was okay to push back on the direction his engineering manager was signaling.” She looked a little startled at her own answer. “He was asking me to give him permission to use his own judgment.”

Roshan let that sit. Then: “And instead you gave him information.”

Not as a criticism. Just as an observation. Priya knew the competency framework — she’d been trained on it years ago — but hearing it land in a specific moment felt different from knowing it abstractly. She had occupied the Teaching/Mentoring stance automatically, because that stance was her default, because that stance felt useful and responsive and comfortable. And she had completely missed what the person in front of her was actually asking for.

“What would coaching have looked like in that moment?” Roshan asked.

Priya thought for a long time. “Probably something like: ‘What’s your actual view on it?’ And then listening. And then maybe: ‘What would you need to feel confident acting on that view?’”

“And you would have learned something from his answer.”

“Yeah.” She was quiet for another beat. “That’s the other thing. When I teach and mentor, I’m the one with the answers. I’m not actually curious. I’m — demonstrating competence. But when I coached just now, just in this conversation, I had no idea what you were going to ask next and I had to actually think.”

That’s the competency framework doing its work — not in a training room, not in an abstract self-assessment exercise, but in the specific moment where a coach notices the gap between the stance they chose and the stance that was actually needed. It’s not comfortable. It doesn’t feel like a success. It feels like being caught doing the thing you already knew you shouldn’t do.

But it’s also the moment where something shifts. Priya went back to Tomás the next week. She asked him what his actual view was on the architecture question. He had a view. A good one, it turned out — careful, specific, aware of the risks in both directions.

He just needed someone to ask.

Go Deeper

• Adkins, L. (2010). Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Upper Saddle River, NJ: Addison-Wesley. The essential reference for the competency framework and the definitive book on the coaching stance in agile contexts. Adkins writes with the precision of an ICF-certified coach and the practicality of a seasoned practitioner. If there is one book on this page’s reading list you actually read, make it this one.

• Agile Coaching Institute. agilecoachinginstitute.com. Founded by Adkins and Spayd, the ACI is the organizational home of the competency framework. The site includes the framework itself, self-assessment resources, and training programs for coaches at various stages of development.

• International Coaching Federation (ICF). coachingfederation.org. The ICF defines the professional coaching competencies that underpin the “Professional Coaching” domain in the ACI framework. Their Core Competencies document — freely available on the site — is the clearest articulation of what professional coaching actually is, which makes it valuable reading for anyone who uses the word “coaching” in a professional context and wants to know whether they mean it.

• Kimsey-House, H., Kimsey-House, K., Sandahl, P., & Whitworth, L. (2018). Co-Active Coaching: The Proven Framework for Transformative Conversations at Work and in Life (4th ed.). Boston: Nicholas Brealey Publishing. Co-Active Coaching is one of the most widely used professional coaching models, and it goes deep on the listening and presence dimensions that distinguish genuine coaching from well-intentioned advice-giving. The Co-Active model is a useful companion to Adkins’ work — where Adkins situates the coaching stance within the agile coaching context, Kimsey-House et al. develop the mechanics of that stance in rigorous detail.

• Spayd, M. & Adkins, L. (2011). “Coaching the Agile Coach.” SolutionsIQ. Spayd and Adkins’ original article laying out the argument for why agile coaches need coaches — and why the competency framework is as much about the coach’s own development as it is about the teams they serve. A shorter entry point than the book if you want to understand the framework’s underlying philosophy before diving into the full treatment.