1 Overview
An Agile coach is often hired to help a team or organization improve how it delivers software. The work includes teaching Agile principles, facilitating Scrum or Kanban adoption, and helping people inspect and adapt their own process. The coach observes how work actually flows, asks questions, and introduces experiments. Over time, the goal is for the team to run those experiments without outside help. That is what it means to work yourself out of a job: the coach's success is measured by how little the team needs the coach.
This article treats Agile coaching as a role, not a permanent fixture. It compares how that role interacts with Scrum and Kanban, two common methods for organizing software delivery. Scrum provides a small set of roles, events, and artifacts that create a regular cadence for planning and review. Kanban provides a visual workflow, explicit policies, and limits on work in progress to improve flow. Neither method requires an Agile coach forever. In fact, both are healthier when the team owns the method and the coach becomes unnecessary.
The honest trade-off is that coaching can create dependency if it is not designed to end. A coach who becomes the permanent facilitator, backlog manager, or conflict resolver may be solving problems the team should learn to solve. The alternative is to treat coaching as a capability-building role with explicit exit criteria. That approach respects the team's ownership and keeps the coach focused on transferring skills rather than becoming a bottleneck.
2 The problem this method was built to solve
Agile coaching emerged because many organizations struggled to adopt Agile ideas in practice. Teams were told to be Agile, but their existing habits, management structures, and incentive systems pulled them back toward big-batch, plan-driven work. Coaches were brought in to help bridge that gap. They translated principles into daily practice, helped teams run Scrum or Kanban, and worked with managers to remove systemic obstacles. The problem was not a lack of frameworks; it was a lack of local capability and organizational support.
Scrum was built to solve a related problem: complex product work needs short feedback loops, clear ownership, and regular adaptation. It addresses the risk of long projects that deliver the wrong thing by creating a cadence of planning, execution, review, and retrospective. Kanban was built to solve a different problem: work often piles up, priorities shift, and teams lose sight of flow. It addresses the risk of too much work in progress by making the workflow visible and limiting how much work is active at once.
An Agile coach sits across these problems. The coach helps a team choose or adapt a method, but the deeper goal is to build the team's ability to solve its own delivery problems. If the coach becomes the permanent answer, the original problem, lack of local capability, has not been solved. The method, whether Scrum or Kanban, is a tool for learning, not a destination that requires a permanent guide.
3 How one cycle runs, from ready to done
In Scrum, one cycle is a sprint. Work is selected from a product backlog during sprint planning, guided by a sprint goal. The team forecasts what it can finish in the sprint, then works toward that forecast. Each day, the team coordinates in a short daily meeting to inspect progress and adapt the plan. At the end of the sprint, the team reviews the increment with stakeholders and holds a retrospective to improve how it works. The cycle then repeats with a new sprint. The coach may facilitate these events early on, but the goal is for the team to run them independently.
In Kanban, one cycle is not a fixed timebox. Work moves continuously through a defined workflow, such as options, ready, in progress, review, and done. The team pulls work into each stage only when capacity allows, guided by explicit policies and work-in-progress limits. There is no required sprint boundary. Instead, the team holds regular flow-focused meetings, such as a daily standup around the board or a replenishment meeting to refill the ready queue. Reviews and retrospectives still happen, but they are often triggered by flow data or a regular cadence chosen by the team.
An Agile coach helps design and improve these cycles. In Scrum, the coach might focus on making sprint goals meaningful and retrospectives actionable. In Kanban, the coach might help define policies and set initial WIP limits. In both cases, the coach's exit strategy is to make the cycle self-correcting. The team should be able to run the cycle, read its own signals, and adjust without the coach in the room. That is the point at which the coach's job is done.
4 Roles and how they divide the work
Scrum defines three accountabilities: Product Owner, Scrum Master, and Developers. The Product Owner maximizes value by ordering the product backlog and clarifying what is needed. The Scrum Master helps the team and organization understand and apply Scrum, removes impediments, and facilitates improvement. Developers do the work of creating the increment. An Agile coach is not one of these roles. The coach works alongside them, often with the Scrum Master and Product Owner, to build capability. The coach may temporarily fill gaps, but the goal is to strengthen the people who own those accountabilities.
Kanban does not prescribe roles. It focuses on the workflow and the policies that govern it. Teams using Kanban may still have product managers, engineers, designers, and testers, but the method does not assign specific accountabilities like Scrum does. Some teams define a flow manager or service delivery manager to watch the board, manage WIP limits, and help unblock work. Others distribute that responsibility across the team. An Agile coach in a Kanban context helps the team make these choices explicit and ensures that no single person becomes a permanent bottleneck.
The coaching role itself should be temporary. A good coach makes their own role unnecessary by transferring facilitation, measurement, and problem-solving skills to the team. In Scrum, that means the Scrum Master and Product Owner grow into their accountabilities. In Kanban, it means the team owns its policies and flow metrics. The coach's exit is not an abandonment; it is the intended outcome. If the coach is still running the board or the retrospective after many months, the team has not yet taken ownership.
5 Artifacts worth keeping
Scrum produces a product backlog, a sprint backlog, and an increment. The product backlog is the ordered list of everything that might be needed in the product. The sprint backlog is the set of items selected for the sprint, plus a plan for delivering them. The increment is the sum of all completed work that meets the team's definition of done. These artifacts are useful because they make work visible and create a shared reference for planning and review. An Agile coach helps the team keep these artifacts lightweight and meaningful, rather than letting them become bureaucratic overhead.
Kanban produces a visual board, explicit policies, and flow metrics. The board shows the workflow stages and the work items in each stage. Policies describe how work moves, when it is considered ready, and what done means. Flow metrics, such as cycle time and throughput, help the team understand how quickly work moves and where it gets stuck. These artifacts are worth keeping because they support continuous improvement. The coach helps the team choose a few metrics that inform decisions, not a dashboard that no one uses.
Across both methods, the most valuable artifact may be the improvement experiment. In Scrum, retrospectives generate experiments for the next sprint. In Kanban, flow data and regular reviews generate changes to policies or WIP limits. An Agile coach should ensure these experiments are recorded, tried, and evaluated. The artifacts that matter are the ones that change behavior. If a board, backlog, or metric is not helping the team deliver better, it is a candidate for removal. The coach's job is to help the team tell the difference.
6 Where this method breaks down
Agile coaching breaks down when it becomes a permanent dependency. If the coach is the only person who can facilitate a retrospective, resolve a conflict, or interpret flow metrics, the team has not built its own capability. This can happen when the coach is rewarded for being visible and busy rather than for making themselves unnecessary. It can also happen when managers expect the coach to fix teams instead of changing the system around them. In those cases, the coach becomes a temporary painkiller rather than a cure.
Scrum breaks down when sprints become mini-waterfalls or when the cadence is treated as a rigid rule rather than a tool. If the Product Owner cannot make decisions, or if the team is not empowered to choose how much work to take on, the events become theater. Scrum also struggles when work arrives unpredictably and cannot wait for the next sprint. In those contexts, Kanban may be a better fit, or the team may need a hybrid approach with explicit policies about what can interrupt a sprint.
Kanban breaks down when it lacks a forcing function for reflection. Without regular reviews and retrospectives, a Kanban team can optimize locally while missing strategic changes. It can also become an excuse to avoid planning or prioritization, leading to a board full of low-value work. An Agile coach must watch for these failure modes and help the team choose the right method, or combination, for its context. The honest trade-off is that no method is universally better; each has conditions where it thrives and conditions where it struggles.
7 Frequently asked questions
How long should an Agile coach stay with a team? There is no fixed duration, but the coach should have explicit exit criteria from the start. These might include the team running its own ceremonies, owning its backlog or board, and using metrics to make decisions without the coach. A reasonable pattern is to reduce involvement gradually over several months, checking whether the team can sustain its practices when the coach is absent. If the team still needs the coach for basic facilitation, the exit criteria have not been met.
Should a coach choose Scrum or Kanban for a team? The choice depends on the nature of the work. Scrum suits product development where a regular cadence, a clear product owner, and a cross-functional team can focus on a sprint goal. Kanban suits work that arrives continuously, has varied sizes, or needs to be delivered as soon as it is ready. Many teams use elements of both. The coach's job is to help the team understand the trade-offs and choose deliberately, not to impose a favorite method.
What does success look like for an Agile coach? Success is a team that no longer needs the coach. That means the team can plan, coordinate, review, and improve without external facilitation. It means the Scrum Master and Product Owner are growing in their roles, or the Kanban team owns its policies and flow. It also means the organization has removed systemic barriers rather than relying on the coach to work around them. When the coach leaves and the team continues to improve, the coach has done the job well.