Choosing an Agile Coaching Stance

I entered the world of agile coaching from standards and compliance-based software process improvement. After reading several recommended books and articles, I noticed that a common theme in agile coaching is the use of different stances. Although the idea of using stances to guide the approach to interacting with individuals, teams, and organizations appealed to me, the books and articles were light on guidance on choosing a specific stance.

Coaches and Consultants

One paper, Choosing a Consulting Role: Principles and Dynamics of Matching Role to Situation, by Douglas P. Champion, David H. Kiel, and Jean A. McLendon provided the insight I wanted.

Consulting Role Grid

I saw parallels between the consultant-client relationship and the relationship between an agile coach and the employing organization. This paper also introduced the consulting role grid, a grid of roles, and representative statements of those roles. The x-axis is the responsibility for project results, and the y-axis is the responsibility for client growth. Throughout an engagement, the consultant may play several roles. The consultant considers factors including the characteristics of the client and consultant, the relationship between the client and consultant, and the organization’s needs when choosing a role.

Stances

Rather than use the term “role” as in the Champion paper, I prefer “stance”, after Barry Overeem’s The 8 Stances of a Scrum Master. I see an individual’s role as the function they play. A stance reflects how someone approaches their role. Throughout their work, an agile coach would take stances to help the organization or teams on the application of agility.

When discussing the stances, the work supported by the agile coach depends on the background of the coach. It ranges from technical skills in product design and delivery to project or product management to organizational behavior, or some other combination of skills. The ability to take on a given stance in a situation depends on the coach’s background and the needs of the organization.

Reflective Observer

The Reflective Observer stance provides an opportunity to focus on observation and giving feedback. This entails watching the way the team goes about their work and asking questions to understand what the team is doing and why they are doing it.

I find the Reflective Observer stance useful when starting to work with a new team. I use it to understand the existing dynamics within the team and between the team and external actors. Finding opportunities for improvement and the most effective strategies for implementing improvements is easier in a stance that centers on observation.

The Reflective Observer stance also gives the coach an excellent position to check on the health of the team. If I have been working with a team for a while, I step back into the Reflective Observer stance to observe how the team has evolved, ensure that the team is capable of functioning without dependence, and learn what skills require further development. I can support the technical, business, and transformational growth of the team. By stepping into the Reflective Observer stance, I can choose a new stance to step into that would allow me to help develop the team.

This stance comes with risks for the agile coach. To an outside observer, it can look like the coach is not doing anything. Staying in this stance for an extended period could result in questions about the value of the agile coach. I ensure that the organization understands the purpose of the Reflective Observer stance and how I take advantage of it.

Modeller and Partner

I take on the Modeller or Partner stance when asked to help the team improve a skill. In the Modeller stance, I take on responsibility for doing the work while making the technique visible and answering questions about the methods. In the Partner stance, I work with members of the team to carry out the work together and address any questions that come up.

The specific stance depends on the familiarity of the team with the techniques. If the team has some familiarity, then the Partner stance is better. If the methods are new, the Modeller stance is often a better starting point. I’ve used these stances to teach a team technical and business skills, but have found that the hands-on approach does not provide a lot of opportunity for the team to grow and own their culture.

I have found it challenging to be a Modeller or Partner for multiple teams simultaneously while also promoting self-organizing teams. Both are hands-on and require involvement in the day-to-day workings of a team. Being involved adds constraints as the teams schedule various meetings and events that would need the coach to be in attendance.

Counsellor and Coach

When I am in the Coach or Counsellor stance, I have limited involvement in day-to-day work. As a Coach, I watch the team performing their work while offering guidance and suggestions. As a Counsellor, I rely on the team to share their experiences so that I can give advice.

I have found these stances to be useful when the team is adept at experimenting with techniques or when the team is making slight changes to their way of working. Both stances put the execution into the hands of the team, but with the coach available for feedback. Although suitable for business, technical, and organizational growth, these hands-off stances allow the team to grow their interactions and way of working.

When working with multiple teams, it may be challenging to take on the Coach stance for all of them. In an environment with self-organizing teams, the coach should not be a bottleneck. In these cases, the Counsellor stance may be more appropriate, with the Coach stance used intermittently with the different teams. When working with an individual team, the Counsellor stance may present a similar problem as the Reflective Observer. To an outsider, it may seem like the coach is not doing much.

Facilitator

In the Facilitator stance, I take a hands-on approach to carrying out the supporting work. This includes scheduling meetings and events, recording and updating notes and data, running meetings, and similar tasks. The team may watch and learn techniques, but there is no explicit transfer of knowledge.

This stance runs the risk of falling into an anti-pattern where the agile coach acts as the team secretary. A good coach has experience in agile and lean practices, teaching, mentoring, coaching, facilitating, and mastery in technical, business, or organizational change skills. Relegating someone with these skills to a purely administrative role is a disservice to the team and organization.

I try to avoid the Facilitator stance. Instead, I prefer to find who should own the activities and take on the Partner stance with those people. When I am present, I help take the burden off the responsible team members, but I also expect all team members to function independently. I try to build the facilitation into the hands-on stances, such as Coach, Modeller, Partner, and Technical Advisor.

Technical Advisor and Teacher

Both the Technical Advisor and Teacher stances are about conveying knowledge to the organization. In the Teacher stance, I give training sessions. As a Technical Advisor, I supply guidance and answer questions that arise as the team works through a problem.

Both stances require the team to be mature. In the case of the Teacher, the team must be able to put the lessons into practice without ongoing oversight from the coach. When interacting with the Technical Advisor, the team must understand how to ask good questions or how to frame problems.

I have not found the Teacher stance to be useful when working with a team. It provides an opportunity to introduce new technical or business practices to the team that can then be implemented. However, I have found it helpful when collaborating with other agile coaches or a team’s external stakeholders. When working with other coaches, the Teacher stance can convey lessons learned to further the practice of coaching. With external stakeholders, the classroom-style setting can be useful to help them understand the team’s way of working and practices.

The Technical Advisor is a good stance to step into after identifying an impediment, often related to the product or service development activities. It is not as hands-off as the Reflective Observer stance and focuses on diving into a problem. It lets the team keep their independence while finding solutions to the hardest problems that the team is facing. It is a suitable stance to help get the team over an impediment before stepping back into a more general stance, such as Coach or Partner.

Hands-On Expert

A Hands-On Expert takes on work as if they were a member of the team. A coach in the Hands-On Expert stance has little responsibility or time dedicated to enhancing the capabilities of the team or the organization.

I avoid the Hands-On Expert stance. For efforts where failure can be disastrous for the organization, it may be necessary to take this stance temporarily. This stance does not promote an environment where teams are self-organizing.

Onwards, Towards Improvement

There’s room for a variety of stances in a coach’s toolbox. Each coach will not be equally adept at using all the stances. An individual’s personality, education, experience, relationships, and current context will all affect the ability to use a given stance effectively. A good coach should understand not only the stances but also the factors that contribute to their success.

I have found that the stances that are more hands-on and involved are useful for building the skills related to product and service design, development, and delivery. The stances that are more observational and hands-off can support the technical and business skills of the team, but are better suited to guiding the team on a path for developing a culture that is more consistent with the desired values and principles.

As I work with different teams in more situations, I will be refining my thoughts. Hopefully, this will be valuable to others to help in making decisions on what ways of interacting with a team may be beneficial for the current context.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.