Agile Coaching. A seemingly simple term that causes so much confusion. Much of the confusion seems to stem from the reasonable question of “what does an agile coach do?” ACI (Agile Coaching Institute) defined an Agile Coach Competency Framework. I’ve used the framework over the years both for agile coaching and leadership. I find it valuable to help people to understand the different perspectives they can approach agile coaching from. We use the framework as a one tool in Advanced Scrum Master Training (A-CSM) and as one set of approaches and skills in Leading Amazing Teams Training. We find it offers leaders insights into how they can shift from a leader-follower to a leader-leader approach to leadership. ACI had a whitepaper outlining the framework (created by Lyssa Adkins and Michael Spayd on a website – no longer active). This article includes my summary of it based on multiple sources — as well as my personal experience with it and ways to learn from it.
Understanding ACI’s Agile Coach Competency Framework
ACI’s Agile Coach Competency Framework breaks agile coaching into eight competencies and a coaching stance. As I have used the Framework with people and teams, there are many insights and ideas I take away from the framework that may or may or may not have been intended. This is one of the reasons I like the framework – there are always new lessons in the looseness of it.
Given this is a framework and not a model (a model would include significant details spelling out learning objectives or even explaining “how” to do agile coaching), expect that each time you use it with people, you will learn new things. This can’t be overstated. Additionally, since this is not a model, perhaps that leads to confusion — since some may be looking for more details.
A few things to know as you read. I will talk about what “space” you are standing in or coming from. You can imagine yourself actually standing in one of these spaces on the diagram below (or in the photo). Standing in Teaching for example and bringing that mindset, perspective, or approach to the situation you are using it in.
Domain Competencies
There are three “domain” competencies: technical mastery, business mastery and transformation mastery. I show them in light green in the
diagram. Technical Mastery is focused on the technical nature of the work you are doing. This was defined as software development (architecture, software craftsmanship, etc.), however I have not used it as only software for a long time. Technical would simply be the technical nature of whatever industry/work you are engaged in. If you work in marketing, procurement, or talent – then think about the technical knowledge about that work. Business Mastery is focused on helping the organization with strategy, operations, process, and product innovation. How does the organization create revenue and deliver value? Transformation Mastery is focused on change leadership, organizational change, facilitation, and helping organizations transform and evolve.
For domain competencies, the initial thinking (from ACI) was that most people would typically focus on one of these areas for mastery. I believe this is typically true given the potential depth of each area. For a long time, I felt like I had a foot in transformation and foot in business. Then I was mainly focused on transformation. However I’ve shifted now and find I tend work in all three in some ways. That does not mean I am ‘all in’ in all three, but I do some work in each domain. It is very hard to specialize in all three, simply from a time perspective. I also find that there is some fuzziness when we look some concepts (e.g. lean and/or theory of constraints). Using those two examples, these can be very business focused to a lot of people, but there are core elements of both that have to do with culture and transformation of more than simply a business process.
The term “mastery” is used with each of these terms (e.g. business mastery). This does not mean that you have mastery in any of the domain competencies (although you may have deep knowledge in any of them), it means you are working towards mastery as a journey. I look the domain competencies from the frame of T-shaped people. You may have a lot of depth in one area, but you can still have knowledge in other areas.
I know a number of agile coaches that are focused on technical mastery and can do amazing things in the transformation space as well. One way to identify your passion is to ask yourself this simple question: “if you had $3,000 to spend in training, where would you spend the money?” For me, I tended to answer — the transformation space. But that is just me, where would you spend it? There is certainly not one right answer on which one you need to focus on as an agile coach or as a leader. We need people who bring knowledge from all of these domains! One of the most important points to really let sink in is that none of these is more important than the other. They are all valuable and needed. Many people find they focused on one and have moved to another over time. That is okay as well, as long as you are satisfied where you are.
Content and Group Process Focused Competencies
There are two process competencies (facilitation and professional coaching) and two content competencies (teaching and mentoring). These are in blue in the diagram.
Process and content competencies are a bit different than domain competencies. The agile coach is at choice (ideally) on where to stand as a coach, based on the clients needs. There are factors that may influence their ability to be fluid and provide coaching from all four, which I’ll talk about later.
Content Focused Competencies
On the left side, we have teaching and mentoring. These are typically about imparting knowledge (or “content”).
Teaching is really just that, it is about teaching people something. This could be teaching them how to (actually) use kanban, why ignoring change transitions will stop your implementation in its tracks, or how leaders can use different options when engaging with teams for success. Typically teaching has some pre-defined outcomes or objectives. This is where an agile “expert” may help people learn how to do something. This is certainly needed by many clients in many situations, especially as they get started with agile or when learning about new ideas (remember that training is not the same as telling).
Mentoring is also based on your knowledge. Mentoring might sound like “in my experience… I tried this and… .” You are still relaying your experience, but in a more subtle way and are less likely to have a ‘training agenda’. It is important to note that mentoring is also not about telling. You are not telling someone what to do. You are typically sharing some content knowledge for them to consider or helping them with confidence around some situation. The person or team you are mentoring should still own the decision. If you are doing this well, they should grow their capacity and “capability” over time.
Process Focused Competencies
On the right side, we have facilitation and professional coaching. These competencies are more focused on holding a process or space for people to bring their intelligence and creatively to tackle challenges, learn, and improve. This does NOT mean people who desire teaching and mentoring are not intelligent! It only means that specific to the items they are working on, teaching and mentoring is more appropriate. Another way to look at it is that on the right, we are helping people to uncover ideas and knowledge they were not aware they have.
Facilitation is about holding an impartial stance. You may facilitate a delivery team during a retrospective or an executive team in a strategic planning session, but you are impartial. Your goal is to hold them to the agreed-on guidelines, but you do not have a specific expected outcome. When you come across a person who is supposed to be facilitating but is not impartial — you can quickly see why this creates conflicts. They are not impartial.
Professional Coaching is about being impartial to the goal. Coming from professional coaching, you believe, truly, that the team can solve the problems they have. You work with them to help the team to solve those issues and be their best selves. I believe this is the most challenging space to stand in because it requires you to trust and honor the wisdom of the people and the team. That is not trivial, even in the best organizations in the world. Coaching a team from the professional coaching space means that you are not teaching by imparting specific knowledge about a solution. You are helping the team to solve the problem via their own knowledge (which is always greater than believed). I typically start coaching engagements from this space (this is my preference – it may not be yours).
Agile & Lean Practitioner
The premise of the Agile and Lean Practitioner competency is that anyone who is an agile coach must have deep knowledge of agile and lean. Where this gets more interesting (to me at least) is when you look at agile and lean combined with say technical mastery. You may have a lot of experience with agile and lean from a technical software development standpoint, but less with organizational transformation (or vice versa). So the domain competencies start to play together with each person’s foundational experience with agile and lean.
The Coaching Stance
The coaching stance is what ACI refers to as “the heart” of ACI’s Agile Coach Competency Framework. The coaching stance is supposed to be the place you start from and return to. The elements highlighted (in the whitepaper) are maintaining neutrality, serving the client’s agenda, reducing client dependence, not colluding, and signature presence. Signature presence is similar to “bring yourself” (which I talk about in Thoughts on Agile Coaching). I have thought about the coaching stance like a “coaching home” where you can check-in to ground yourself.
You can think about your coaching approach as an awesome pair of shoes. Think about the most comfortable footwear you have — this could be dress shoes, bunny slippers, flip flops, sneakers, boots, just socks or even just bare feet (or bear feet if that works). As you consider which competency helps inform the coaching situation (more on this below) you are working on, consider the footwear you are wearing. Are you bringing your best-self to the people and teams you work with? Are you in service with the people in the teams? Are you helping them, in the best way possible, to be amazing? You should be wearing the footwear that grounds you and guides you in your service to the client. These “shoes” are something you can wear as you move around the competencies. They ground you — in you! This also helps a lot to ensure you are taking care of yourself!
In Learning from ACI’s Agile Coach Competency Framework (Part 2), I discuss ways to use the framework to bring new insight to your coaching, your teams, and yourself.
Very nice summary. I like your take on this.
Thank you!