Five Agile Coaching Postures and How to Apply Them Effectively

Interestingly, an agile coach must be able to perform many tasks that are not strictly coaching.

One core skill is knowing the right moment to coach and when to switch to another role.

For example, if a team does not understand why work should be broken into small, independent tasks, a pure coaching approach would require patiently guiding them step‑by‑step until they grasp the intent, demanding near‑superhuman logical and inductive abilities from both the team and the coach. A more efficient method is to temporarily adopt a lecturer role.

Coaching and lecturing are two different "operational modes" we call coaching postures. This article explores five postures, as shown in Figure 1. You must always be aware of the posture you are currently using and be ready to change it as the situation demands, employing different techniques for each posture.

Figure 1: Coaching Postures

In most cases, your default posture is Coach. In this posture you listen, observe the team’s work, challenge their assumptions, guide and lead them to act.

The coaching posture aligns with systemic coaching, remaining neutral and avoiding imposing personal ideas on the team. To prevent bias, you should stay in the coaching posture whenever possible.

The Lecturer posture is one you use frequently. Unlike a sports coach, an agile coach must also be able to educate and lecture.

In this context, "lecturing" means that when a team lacks knowledge in a certain area, you detect the gap, clearly explain the concepts, answer related questions, and confirm the team has mastered the new knowledge. This does not require preparing multi‑day, entertaining courses, though many agile coaches also act as agile instructors. Delivering a multi‑day course, however, demands a different skill set.

After lecturing, you should quickly return to the coaching posture by asking questions such as “How do you think this new knowledge will affect your future actions?” or “Given the information I just shared, what do you think is the best next step?” This signals the coachee to take responsibility and use the new knowledge to make informed decisions.

The Mentor posture involves transferring expertise from mentor to mentee. It is used when the coachee has some knowledge but lacks experience in the domain. Knowledge transfer can occur through discussion, storytelling, sharing anecdotes, giving advice, hands‑on demonstration, collaboration, or pair‑working, often resembling an apprenticeship.

Mentoring can be easily confused with coaching because a good mentor must also be a good listener and coach. Many mentor programs include career and life‑coaching elements, and coaches sometimes need to act as mentors, especially when guiding junior agile coaches or Scrum Masters.

The Consultant posture involves offering advice to the client when necessary, providing multiple options, original insights, and evaluating the client’s experience. You must substantiate your ideas and explain your reasoning, while remaining cautious because coaching and consulting can conflict; coaching requires neutrality, whereas consulting expects concrete recommendations.

Clients may seek advice not for factual answers but to vent frustrations or explore how you might support their agenda. When giving advice, you must be responsible for your words, avoid conflicts of interest, and recognize that simple questions can have complex answers.

Typically, we respond to clients with “It depends on the situation,” then possibly explain relevant theory (training), help them find their own answer (coaching), or provide illustrative cases (mentoring). Direct, prescriptive advice is rare and we rarely implement the solution for them.

Even when giving advice, you should let the coachee retain responsibility. One technique is to frame suggestions as hypotheses, e.g., “Could you consider…?” or present options: “Another approach worth exploring is…”. This signals that the coachee must devise the solution, reinforcing the coaching posture.

The Role‑Model posture emphasizes embodying agile and lean values through integrity, transparency, honesty, and a focus on helping people and delivering maximum client benefit. It is about living the values rather than merely providing external consulting services.

For example, a coach should not be late to meetings they demand start on time, nor should they appear clueless about their own tasks while expecting Scrum Masters to be prepared.

Role‑modeling differs from external contracting or consulting; it is an internal activity that provides on‑the‑job training for Scrum Masters, such as ensuring retrospectives run smoothly and guiding teams toward desired behaviors.

When acting as a role model, you may lead several sprints and gradually hand over activities to internal Scrum Masters, covering most of the scope typically defined in a coaching contract. This contrasts with a sports coach who never scores on the field or a consultant who changes the client’s system.

If your contract includes contracting or consulting services, we can discuss embedded coaching. An embedded agile coach works as a team member or Scrum Master on a full‑time basis for months, promoting agile practices throughout the organization. While this seems cost‑effective, it carries risks for both coach and client, so we generally avoid such contracts.

Embedded coaches may lose credibility over time as they become part of the team, with managers issuing directives. Their guidance focuses on implementing the chosen agile method, which can slow progress. Teams may become dependent on the coach, and when the coach leaves, agile adoption may stall. The coach also faces conflicting goals, making satisfactory outcomes rare.

Compared to a focused agile coach, an embedded coach must learn double the professional content but has less time to apply it. Their experience is limited to a specific client, reducing exposure to diverse contexts. Switching between roles requires clear identity; constantly toggling creates confusion for others.

When providing advice or role‑modeling, an agile coach should avoid getting involved in product or content decisions. Remember, the goal is to improve the organization, not the product.

Positioning yourself within the organizational system can make it hard to stay objective and fair. Unless you are a recognized domain expert, the organization you coach likely knows its customers better than you do.

Reference: The Hitchhiker’s Guide to Agile Coaching

Play LEGO, learn agile, Scale Agile Collaboration Sandbox “Utopia Plan” – March 5‑6 2022 in Shenzhen, bringing multi‑team agile collaboration into the development process to boost R&D efficiency.

Both enterprises and individuals can register to join the “Geek Utopia” challenge.