Agile Coaching: Guiding a Team Through Adoption

Agile coaching for teams in adoption: map how they work today, add one practice at a time with their consent, and hand the process over to them.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Agile coaching is the work of helping a team, and often the organization around it, learn to work in an agile way. Agile adoption at team level means changing habits: how work is planned, how people coordinate, how decisions get made. Habits change slowly and only when the people involved see a reason. A coach's job is to make that change safe, specific and owned by the team.

Lyssa Adkins, in her book on coaching agile teams, lists the coach's roles as "teacher, mentor, problem solver, conflict navigator, and performance coach" (Adkins, Coaching Agile Teams). The book's description notes that moving from "command and control" to agile coaching "requires a whole new mind-set", and that a coach stays "actively engaged without dominating your team." In Scrum, much of this work belongs to the Scrum Master, whose responsibilities include "Leading, training, and coaching the organization in its Scrum adoption" and "Coaching the team members in self-management and cross-functionality" (Scrum Guide).

A common risk in an agile transformation is imposing it. Martin Fowler, one of the Manifesto's authors, calls the Agile Industrial Complex imposing methods on people "an absolute travesty" and states that "The team doing work decides how to do it. That is a fundamental agile principle" (Fowler, State of Agile Software in 2018). A coach who installs a framework by decree gets compliance with the ceremonies and little of the value.

Learning also happens in stages. Fowler describes Shu Ha Ri, a model from Aikido that Alistair Cockburn brought into software: in Shu, students "follow the teachings of one master precisely"; in Ha, they learn the underlying principles; in Ri, they adapt what they have learned to their own circumstances (Fowler, ShuHaRi). A team new to agile usually needs clear practices first, and the coach's aim is to move it toward adapting those practices itself.

This skill is a sequence for coaching one team: understand where it is, introduce practices one at a time as experiments, hand facilitation over, and plan your own exit.

How It Works

Start from the team's problems. A team adopts a practice when it solves a problem the team feels. Before introducing anything, the coach observes how work actually flows and asks the team what frustrates them. The first practice should address one of those frustrations directly.

Introduce one practice at a time, as an experiment. Changing many habits at once makes it impossible to tell what helped and overwhelms people. Each practice is framed as a time-boxed experiment with a clear question: did it help? The team reviews the result and decides whether to keep, adjust or drop it. That decision is the team's.

Teach the why with the what. A practice copied without its purpose degrades into ritual. When introducing a daily standup, a retrospective or a WIP limit, the coach connects it to the value or principle behind it. Over time the team should be able to explain each of its practices in terms of the agile principles.

Model, then hand over. In the Shu stage the coach often facilitates the first few sessions to show how they work. Then team members take turns facilitating with support, then alone. A coach who keeps running every meeting creates dependence.

Watch technical practices too. Fowler's "Flaccid Scrum" describes teams that adopt Scrum's practices, after which "progress is slow because the code base is a mess" (Fowler, Flaccid Scrum). Coaching that covers only meetings misses the engineering habits that keep change cheap.

Measure health with the team, for the team. A simple self-assessment gives the team and coach a shared picture of progress. Spotify's squad health check has teams rate areas such as "Easy to release", "Suitable process" and "Fun" as green, yellow or red, and stresses that "the primary audience is the team itself rather than management" (Spotify, Squad Health Check). Its authors warn against comparing teams with it.

Step-by-Step Guide

Step 1: Observe the current state

Spend time with the team before changing anything. Watch how work arrives, how it is planned, how people coordinate and where it waits. Talk to each person individually about what works and what frustrates them. Write a short summary of what you saw, without judgment, and check it with the team.

Step 2: Agree the coaching goals with the team and sponsor

Share the summary and ask the team which problems matter most to them. Meet the sponsor separately to understand what the organization expects, and reconcile the two. Agree on a small number of goals and how you will all know if the coaching is working. Make clear that the team will choose which practices to keep.

Step 3: Pick the first practice and frame it as an experiment

Choose one practice that addresses the team's top frustration, such as a visible board for work that keeps getting lost or a retrospective for recurring friction. Explain what it is, why it exists, and what question the experiment will answer. Agree on a short trial period and ask for explicit agreement to try it.

Step 4: Facilitate it yourself at first

Run the first few sessions of the new practice so the team sees how it works when done well. Keep them short and focused on the purpose. After each one, ask what helped and what felt like overhead, and adjust.

Step 5: Review the experiment with the team

At the end of the trial, hold a short retrospective on the practice itself. Did it address the problem? What should change? The team decides whether to keep, adjust or drop it. Record the decision and the reasons.

Step 6: Add the next practice

Once the first practice is stable, pick the next one from the team's list of problems and repeat the cycle. Build up the set of practices gradually, and connect each new one to those already in place. Revisit the agile values and principles as practices accumulate so the team sees how they fit together.

Step 7: Hand facilitation to the team

Rotate facilitation of each practice among team members, supporting them the first time and then stepping back. Offer feedback privately. When the team runs a practice well without you, that practice is handed over.

Step 8: Track team health and plan your exit

Run a regular health self-assessment and review the trend with the team. Agree in advance what "ready to continue without a coach" looks like, such as the team running its own retrospectives and changing its process from them. Reduce your involvement step by step as the team reaches it.

Best Practices

• Earn trust before proposing change. Observing and listening first shows respect for how the team works today and surfaces the problems it actually feels.
• Keep the team's consent explicit. Fowler's point that the team decides how to work (Fowler, 2018) is also the fastest path to practices that stick.
• Coach the environment as well as the team. Many obstacles, such as approval chains or fixed-scope commitments, sit outside the team, and the Scrum Guide gives the Scrum Master responsibility for "Removing barriers between stakeholders and Scrum Teams" (Scrum Guide).
• Match your style to the team's stage. A new team may need direct teaching, and an experienced team may need only questions.
• Include engineering practices. Testing, integration and refactoring habits determine whether short cycles are sustainable.
• Plan your exit from the start. A coach who is still running every meeting after months has not transferred the skill.

Common Mistakes

• Installing a framework on day one: Introducing every role and ceremony at once produces confusion and resistance. Start with one practice that solves a felt problem.
• Treating resistance as the problem: Resistance usually points at a real concern, such as extra meetings with no visible benefit. Ask what the concern is and adjust.
• Coaching only the meetings: Teams can run every ceremony and still deliver slowly because of technical debt. Look at how code is built, tested and released.
• Reporting on the team to management: Using health checks or retrospective content to evaluate the team destroys candor. Share only what the team agrees to share.
• Becoming indispensable: If practices stop when you are away, you have been doing them for the team. Hand facilitation over earlier.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Agile

Related Skills

• Running Sprint Retrospectives for Continuous Improvement
• Facilitating the Daily Standup Meeting
• Choosing Between Scrum, Kanban, and Scrumban
• Scaling Agile Across Teams with SAFe, LeSS and More

Sources

• Lyssa Adkins: Coaching Agile Teams
• Ken Schwaber and Jeff Sutherland: The Scrum Guide
• Martin Fowler: The State of Agile Software in 2018
• Martin Fowler: ShuHaRi
• Martin Fowler: Flaccid Scrum
• Spotify Engineering: Squad Health Check model
• Principles behind the Agile Manifesto

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.