Agile Coach

With one team, nobody needs this role. A scrum master keeps the meetings doing their job and clears what the team is stuck on, and that covers it.

Two things come apart as teams multiply. The first is that every team ends up working differently. That's what happened when Pagedeck split engineering into three. One team ran scrum on two-week cycles. One ran kanban, no cycles at all, work flowing across a board. The third mixed the two and called it scrum. Inside each team nothing was wrong. It only mattered on a release that touched all three, where "can it make this cycle?" turned out to mean three different things.

The second is problems a team can't reach. Another department sitting on approvals for two weeks, or reviews scored on individual ticket counts so nobody helps the person next to them — no amount of effort from that team's scrum master touches either, because both live outside the team boundary. The same item comes up in retrospective after retrospective with nobody able to move it, and after the third round the team stops writing it down.

An agile coach is the seat placed outside the teams to handle those two. Rather than living in one team, the coach circulates, names the patterns a team can't see from inside, and carries boundary-crossing problems up to where they can be decided.

There's no defined deliverable here, so a day fills with watching, intervening, and building. No code and no document comes out of it, which is exactly where people new to the role get lost.

1. Sitting in meetings. Two or three daily scrums and a retrospective, attended without facilitating. Who doesn't speak, and what happens next when somebody does say they're blocked — those go in the notes. Roughly half the day goes here.
2. Stepping in occasionally. Not every time, but once, at the point where it lands hardest. When the same item shows up in a retro for the fourth month, the move is to ask whether the plan has a slot for it. Stopping the room with a question instead of an answer is how this role works, because handing over the answer guarantees the coach gets called again next time.
3. Running one-on-ones. Thirty minutes every other week with each team's scrum master or lead. The coach doesn't relay what was seen in the meeting; the first question is what the other person saw.
4. Building things that span teams. Aligning the work units that each team had been naming differently, putting together onboarding for a newly hired scrum master, opening a quarterly session where all three teams look back together. None of this is urgent in any given week, which is why it never gets done by anyone who belongs to a team.

Over a week that's five or six teams at three or four hours each. Take on more and the hours spent sitting in meetings disappear, which leaves the coach knowing only what teams choose to report.

The most frequent counterpart is each team's scrum master. A coach who instructs a team directly hollows out that seat, so the coach usually works through it — passing along what was observed and letting the scrum master raise it with the team.

With an engineering manager the line has to stay drawn. That role owns evaluation and growth for its engineers and therefore holds authority over people; the coach holds none. Blur the two and what the coach sees in a meeting starts feeding performance reviews, and from that moment teams hide their problems from the coach.

With a delivery manager the interests diverge. That role watches whether what was promised ships when it was promised; the coach watches how the promise gets made. Facing the same slip, one looks for a way to pull the date in and the other asks why it always surfaces this late. Both questions are worth asking, and a team that hears only the first learns to report later still.

There are regular sessions with executives as well. Problems outside the team boundary — an approval chain, a review criterion — can't be fixed by the team and have to reach whoever can decide. Without that channel, the coach's work shrinks to giving advice on how to run meetings.

"Can the coach come sort our process out?"

A request to have it done for them, which isn't how the seat gets used.

"The three teams count sprints differently, so we can't plan across them."

The problem spans teams, so it needs someone outside any one of them.

"Nothing the coach sees goes into performance reviews."

Confirming the rule that keeps observation and evaluation apart, which is what makes teams honest.

Pagedeck brought in a coach the quarter engineering became three teams. For the first month all he did was sit in meetings. When Grace asked for a month-one report, what came back wasn't a list of improvements but one sentence: all three teams had raised deployment approval delays in their retrospectives, and all three had done nothing about it the following cycle.

How it got fixed shows what the role is. The coach didn't touch the approval chain. He put the three scrum masters in a room with their retro notes open, had them find the shared item themselves, and sent the three of them to Grace together. When approvals dropped from two stages to one the next quarter, the people who did it were those three, not the coach.

The most common expectation is that hiring a coach fixes how the company works. It looks like bringing in a consultant, so the assumption is reasonable enough. But this seat doesn't supply answers; it gets the team to find them. Solve it for them and the practice leaves the day the coach does, and six months later someone is hiring again for the same problem. Short contracts with "establish the process by this date" attached usually end here. The deliverable arrives on time, gets filed, and describes a way of working nobody in the building chose.

The second is reading the coach as someone sent to spread agile. The job title says agile, so it reads that way. What the seat actually does is find the way of working that fits a given team, and that conclusion can be to drop scrum. Insisting on two-week cycles for a team whose work is half inbound support means the plan collapses every week. Once keeping the framework becomes the goal, the coach ends up on the side that produces dark agile — every form in place, nothing the team actually gets to decide.