Do you need an “Agile Coach”? Probably not.

“Agile Coach” is a made-up thing. I’ve met countless people who hand me a business card with “Agile Coach” on the front. I have worked with stables of coaches from consulting organizations. I’ve lost count of the number of “Agile Coach” job descriptions I’ve been asked to review. Describing the responsibilities, behaviors, and activities of “Agile Coach” often varies among people. And in my experience, asking management to describe how the role delivers value to people comes out vague and equivocal. I’ve observed the role tends to be about “driving” things (process, training, change) and, speaking as someone whose career has primarily been this very title, often does more harm than good. 

I believe “agile”, referring to the Manifesto for Agile Software Development, is ultimately about learning how to effectively deliver software and evolve a software organization in ways which create a competitive advantage. Thus, I assume “Agile Coaching” refers to partnering with people and assisting them with realizing this goal. Therefore, my stance in the description below is software-oriented. Since “Agile Coach” is a made-up thing, you should adapt my belief system to best fit your context.

As a prerequisite to the software focus above, something called “Agile Coaching” requires knowledge of software development and, especially, of agile software development (as expressed by the four values and twelve principles of the manifesto). It makes sense to me that an experienced Agile Coach is able to expertly go both deep and broad across the application of principles.

Which turns me to folks who push (or sell) the “Agile Methodology”. Agile is first a set of beliefs and, second, a set of principles derived from these beliefs. Agile thinkers believe these patterns of thought and behavior are universally applicable to software development. Whatever “Agile Coach” might be, I posit the role needs an appropriate lens for problem solving:

• The belief (value) in team-centric approaches to work are superior to optimizing for role success.
• The belief in product discovery, including design research to foster evolutionary design, as the best path to customer collaboration.
• The belief that smaller steps (in product, in change, etc.) are superior to larger steps and often surprise us. When we get good at small, we pursue even smaller.
• The belief that technical practices are the systemic constraint for software agility. If quality is not built-in and we cannot deliver value safely, all other activities lose utility.
• Validate and learn from everything (closed feedback loops). Adapt throughout the system.

In addition to this belief system of agile done well, “Agile Coaches” are competent in five core personal skill sets which enables them to effectively serve the organization. Working from a people-over-process mindset, they apply the following in her work:

• Systems Thinking: applying knowledge of cause-effect relationships between the structure of the organization (policies, rewards, titles, and containers), exchanges of information and feedback loops, behaviors of people, and differences among the parts.
• Professional Coaching: staying people-focused, curious, being mindful to listen actively, be in service to people’s goals, and firmly, yet kindly, reminding them of their commitment to action (and never doing so without permission).
• Teaching and Mentoring: skillfully navigating the edge between teaching (or lecturing) and modeling (how to do or apply something), training, and collaborating.
• Professional Facilitation: creating the conditions for people to achieve their goals, promoting inclusion and all voices heard, evoking creativity and new insights, evoking a learning organization.
• Emotional Intelligence: continuously applying and improving one’s ability to empathize, be socially aware, navigate emotions and expression, and form interpersonal relationships.

A software organization is a complex, adaptive system made up of many interrelated parts. Parts may be human, mechanical, and/or esoteric. This assembly of systems within systems can be abstracted into three “categories” of focus for an Agile Coach. Given the systemic nature of organizational systems, an Agile Coach cannot be simply isolated to a particular category, as the cause-effect relationship of systems makes such an assumption erroneous. However, an Agile Coach may have one or more focus areas, collaborating with many people across the system to focus on improving the “whole”.

I believe an “Agile Coach” operates within three broad categories of systems:

• Technical systems – codebases, continuous integration and delivery, test suites, packages, and the practices which improve software excellence (e.g., test-first programming, acceptance testing, refactoring, collective code ownership, collaborative coding).
• Team systems – teaching the organization to provide the requirements and needs of real teams (versus working groups), facilitating an environment of self-organization, mentoring and teaching where appropriate and/or requested, and being a trusted partner for interpersonal relationships.
• Organizational systems – structures and processes which affect outcomes across many layers of the organization (e.g., customer relationships, value discovery), closed feedback loops, transformation, transition, and change management, and effective measurement design (ensuring measurement reduces the uncertainty needed for effective decision making).

One might ask, then, “what are the responsibilities of this person in each category?” Of the requests I get from folks, one of the most common is a recommendation for “best practice” Agile Coach job descriptions to aid in hiring and/or alignment. I believe this is where the made-up nature of such a role goes into harmful territory. As stated above, my position is “Agile Coach” is primarily about working with the unique context of a system to achieve the organization’s goals. It is my belief that context is so important, there cannot be a “best practice” set of responsibilities for a role such as one discussed here. For example, Green et al (2016) found that “performance plummets when contextual cues disappear, implying that the expertise we observe on the familiar task is more heuristic than conceptual and does not travel far.”

What about “product systems” or customer focus? Similar to helping folks understand a “team-centric” mindset, I believe this concept is one realization of the importance of systems thinking. For an “Agile Coach” to be focusing on product discovery and customer needs/wants, she requires her attention in all three of the systems described above. For simplicity, I categorize the value of product management as an “organizational systems” characteristic.

Therefore, should your organization decide an “Agile Coach” role is needed, I strongly recommend you audit your perspective of what value she will bring against the beliefs, skills, and behaviors previously described. If you find yourself feeling a need for “driving people”, standardization, conformance, order, and/or an emphasis on process as the catalyst for change, it’s unlikely you need an “Agile Coach”. In fact, it’s my opinion the propensity for folks to impose “Agile Coach” on the organization is one of the primary factors in millions of dollars wasted in the name of “transformation” every year.

However, if the thoughts expressed above resonate with you, it is your job to think deeply and deliberately to define the role in a way which serves your context… and the goals you have within this context. If you find yourself borrowing job descriptions, roles and responsibilities, and other artifacts from popular “best practices” at other companies, stop. Instead, think about the outcomes you want and how behavior change will lead to realizing your goals. Describe how the problem solving lens of “Agile Coach” I defined earlier will be used in your context. Let these thoughts guide your shaping of how the person (or people) will behave in the role, what responsibility you want to assign, and the system(s) you’re willing to entrust.