"The Coaching Conversation Nobody Wants to Have – Part 2"

Part 2 of 2 — The Conversation Itself. Part 1: The Power Problem.

In Part 1 of this series, the argument was structural: the coaching conversation with a manager whose behaviour is undermining the team is not primarily a communication skills problem. It is a power problem. And before the conversation happens, three structural preconditions need to be in place: organisational backing, documented impact, and a clear escalation path.

If those preconditions are met – you have documented the behaviour, you have the backing, you know the escalation path – then this article is for you. You have done the structural work. Now you have to walk into the room.

---

The Hook: The Moment Before the Door Opens

There is a specific kind of dread that precedes this conversation. It is not the same as ordinary nervousness before a difficult meeting. It is the dread of someone who knows that what they are about to say is true, is important, and may not land well regardless of how skillfully it is delivered.

Most advice about difficult conversations focuses on reducing this dread through preparation and reframing. “It is just a conversation.” “The other person wants to do well.” “Assume positive intent.”

Some of this advice is useful. Some of it is a way of avoiding the honest acknowledgement that this conversation carries genuine risk, and that pretending otherwise does not protect you – it just sends you into the room underprepared for what might happen.

The goal of this article is not to eliminate that dread. It is to give you something to do with it.

---

The Reality: What Most Coaching Conversations Get Wrong

The Trap of Indirect Language

The most common failure in this conversation is the use of language that obscures the point. Scrum Masters and Agile Coaches are trained in non-violent communication, empathic listening, and the importance of avoiding blame. These are real skills. They become a liability when they produce sentences like:

“I sometimes wonder whether there might be an opportunity for us to explore together how the team’s experience of Sprint Planning could potentially be different.”

That sentence is saying: “Your behaviour in Sprint Planning is undermining the team’s self-organisation.” The manager hears the first version and responds to that. The actual message – the specific, documented, consequential one – never arrives.

Indirect language feels safer because it reduces the immediate risk of confrontation. What it actually does is transfer the risk forward: the behaviour continues, the team notices nothing changed, and the Scrum Master has to have the conversation again – this time with less credibility, because they were already there and nothing happened.

Be direct. Not blunt, not aggressive, but direct. “In the last three sprints, decisions made during Sprint Planning have been revised before Wednesday. I have the dates and the decisions. I want to talk about what is driving that and what we can do differently.”

The Trap of Problem-Solving Too Early

The second common failure is moving to solutions before the problem is fully on the table. The manager experiences mild discomfort when the behaviour is named, deflects into problem-solving mode, and the conversation shifts to “what can we do better” before there has been any genuine acknowledgement of what has been happening.

This feels like progress. It is not. If the manager has not actually heard and acknowledged the impact of their behaviour, the solutions agreed in the meeting will not change the underlying pattern. They will change the manager’s stated intentions, which may shift the behaviour for one or two sprints before it reverts.

Hold the problem in the room longer than feels comfortable. Acknowledge that problem-solving will come. But it will be more effective once there is shared understanding of what has actually been happening.

The Trap of Over-Personalisation

The third failure is allowing the conversation to become about the manager as a person rather than about specific behaviours and their consequences. This happens in both directions: the Scrum Master frames things in ways that feel like character judgements, and the manager responds defensively as though their identity is being attacked.

The antidote is specificity. Specific behaviours. Specific dates. Specific consequences for specific people. The more concrete the evidence, the less the conversation feels like a character assessment and the more it feels like an operational discussion.

“The moment the conversation becomes about who someone is rather than what they did, the operational problem disappears and the interpersonal one takes over. You cannot solve the operational problem from inside the interpersonal one.” Markus – agile-checksum.com

---

The Checksum: A Framework for the Conversation

This is not a script. Scripts fail the moment the other person says something unexpected, which is always. What follows is a structure that keeps the conversation oriented toward the outcome you need.

Phase 1: State the Purpose Clearly (2 Minutes)

Open by naming what the conversation is about and why it matters. Not a lengthy preamble, not small talk, not “I wanted to catch up.” Something like:

“I want to talk about something specific that I think is affecting the team’s performance. I have some data I would like to walk you through. I am not here to create a problem – I am here because I think there is something we can fix, and fixing it will make a real difference.”

This accomplishes three things: it signals that the conversation is structured and prepared, it frames it as operational rather than personal, and it creates the expectation that evidence will be presented.

Phase 2: Present the Evidence Without Editorialising (5 Minutes)

Lay out the documented behaviour with dates and consequences. Be factual. Resist the urge to explain what you think the behaviour means or what it says about the manager’s priorities. Present what happened.

“In Sprint 14, on the Tuesday after Sprint Planning, the decision to use a third-party API was reversed via email to the team. In Sprint 15, two stories were added to the sprint after the planning session, without discussion with the team. In Sprint 16, three team members told me they felt unable to raise a capacity concern in planning because they expected the plan would change anyway.”

Pause after presenting the evidence. Give the manager space to respond before you move forward.

Phase 3: Listen to the Response Without Immediately Defending

This is the hardest part. The manager will likely do one of several things: explain their reasoning, deny the pattern, express genuine surprise, or become defensive. Whatever they do, your job in this phase is to listen and to understand – not to score points.

If they explain their reasoning: take it seriously. Sometimes there are genuine constraints – pressure from above, stakeholder demands, information the team does not have – that are driving the behaviour. Understanding those constraints does not excuse the pattern, but it may change how the solution is framed.

If they deny the pattern: you have the dates and the data. You do not need to argue. “I understand this might look different from your perspective. I have the specific examples here if it would help to go through them.”

If they become defensive: hold your ground without escalating. “I am not trying to make this personal. I am raising it because it is having a measurable impact and I think we can address it.”

Phase 4: Agree on Specific, Observable Next Steps

The conversation is not complete until there is agreement on what will be different – and what will happen if it is not. This is where the escalation path matters: if the manager knows that an unresolved pattern will be escalated, the agreement in this conversation carries more weight.

The next steps should be specific enough to be verifiable in the following sprint. Not “I will try to be more supportive of team autonomy.” Something like: “Sprint Planning decisions will not be revised after the session without first discussing the revision with the team and the Product Owner. If there is a genuine external constraint that requires a change, I will flag it in the Daily and explain the reason.”

---

Real-World Examples: When It Goes Sideways

The Manager Who Cried

In a retail technology company, a Scrum Master prepared thoroughly for this conversation: three sprints of documented evidence, explicit backing from the transformation lead, and a clear escalation path. The manager, when confronted with the evidence, began to cry.

This is not manipulation (usually). It is a human response to the experience of having one’s behaviour named in a professional context. It is also, functionally, a conversation-stopper – because most people, confronted with someone crying, immediately shift from operational mode to support mode and abandon the point they were making.

The Scrum Master handled it well: acknowledged the emotion, gave the manager a moment, and then gently returned to the evidence. “I can see this is difficult to hear. I want you to know this is coming from a genuine desire to make things better, not to create a problem. Do you want to take five minutes and come back to this?” They did. The conversation continued. The agreement was reached.

The takeaway: emotional responses in this conversation are not the end of the conversation. They are part of it. Acknowledge them, but do not let them derail the point.

The Manager Who Agreed and Did Not Change

A logistics company, a Scrum Master, a manager who received the feedback impeccably. He thanked the Scrum Master for the directness. He described what he would do differently. He was genuine in the room. Two sprints later, the pattern had resumed.

The Scrum Master returned for a second conversation. The manager explained that the pressure from above had increased and he was struggling to maintain the commitments he had made. This was honest and, in some ways, exactly the right disclosure – because it confirmed what Part 1 of this series described: the behaviour was being driven by structural pressure at a higher level, not by the manager’s intentions in the room.

The escalation path was activated. The transformation lead had a conversation with the manager’s own director. The structural pressure was addressed at the level where it could actually be resolved. The behaviour changed.

The takeaway: agreement in the conversation is not the same as change in the field. If the pattern resumes, the escalation path is not a threat – it is the appropriate next step.

---

The Takeaway: What This Conversation Is and Is Not

This conversation is not a confrontation. It is a structural intervention dressed in the language of a professional conversation. Its goal is not to make the manager feel bad or to establish that you were right. Its goal is to change a specific pattern of behaviour that is harming the team – and to do so in a way that is clear, documented, and connected to consequences.

If the conversation goes well, the manager understands what has been happening, commits to specific changes, and follows through. That is the best case.

If the conversation goes less well, the pattern is documented, the escalation path has been activated, and the structural mechanism can take over. That is also acceptable.

What is not acceptable is continuing to watch the pattern harm the team while waiting for a better moment or more perfect conditions. There is no perfect moment for this conversation. There is only the moment you are in, with the preparation you have done.

Run the checksum one more time before you walk in:

1. Can you describe the three most recent specific incidents in one sentence each – observable behaviour, date, consequence?
2. Do you know what the manager’s likely justification will be – and have you thought through how to respond to it without abandoning the evidence?
3. Do you know what agreement you are trying to reach by the end of this conversation – specifically enough to write it down afterwards?

If you can answer all three: open the door.

---

Glossary Terms Used in This Article

• Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team and organisation.
• Sprint Planning – A Scrum event in which the team plans the work to be performed in the upcoming Sprint.
• Sprint – A fixed time-box of 1–4 weeks in which a Scrum team delivers a potentially releasable increment.
• Impediment – Anything that prevents a Scrum team from progressing as effectively as possible.
• Psychological Safety – The shared belief that it is safe to take interpersonal risks within a team.
• Agile Transformation – The process by which an organisation attempts to adopt Agile values and practices at scale.